New release of ngacl

Christoph Klein christophk at cip.wiwi.uni-karlsruhe.de
Sun Aug 21 09:31:21 GMT 2005


On Sat, Aug 20, 2005 at 01:21:56PM +0200, Stefan (metze) Metzmacher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Christoph Klein schrieb:
> > Hi there,
> > though it seems to me, that interest is little for my tiny project, i
> > try once again to gain some attention.
> sorry, I didn't know about it, till now:-)
> 
> > Following your list, i had the impression, that development of ntacl-lsm accellerated last weeks. So me too i had spend some more time on my lsm. 
> > I still think, it would be useful to throw our lsms togeteher, though up to now nobody could explain to me, what the advanteges of storing full nt-secdescs are.
> > They have to be converted every time they are used, and this process doenst
> > seem to be simple.
> I think one of the principles of kernel development
> > is, to do just a few, minor things in kernelspace and everything that
> > can be done within userpace should be done in userspace. The second
> > point is, that i dont see, how you want to resolve SIDs within the
> > kernel?
> 
> The idea I have is:
> 
> 1) having a real security_token with SIDs and privileges stored on each task_struct->security.
I think that is not easy to do, especially if you want to do it in a
secure way. Furthermore i wanted to solve this acl problem for all time
now, ie users logged in locally and users mounting the fs via nfsv4 should profit from the acl system, too. You cant expect, that all these users
have a valid security_token. The only security identifier you can expect
these users to own, is a uid and some gids.

>    and having the unpacked security_descriptor hanging on each inode->i_security.
>    and then do we can provide real NT ACL semantics.
The "right-bits" of ngacl are the same as nt or nfsv4 users. They should
show the same behaviour. Up to now i dont support SYNCRONIZE_ACCESS (i
think this means file locking hook) and SACL (They only genereate log messages, don't they?), but
these arent too complex to implement. The big difference between nfsv4
and nt acl is, that nfsv4 uses static and nt dynamic inheritance.
Currently ngacl supports only dynamic inheritance, but the choice
between these models should be up to the user in the near future.
So what else is still missing for "real NT ACL semantics"?
> 
> 2) the idea to sync the posix acls with the nt acls, was to control
>    the hooks which modify them and then ask a userspace tool to map them,
>    and then both are stored on disk.
> 
> 3) when the task_struct doesn't have a nt security_token, the capablity lsm functions
>    are called to just check the unix uid/gid's against the posix acl
As i have stated above, the way (samba, nfs,..) you access the file
shouldnt determine the rights you are granted for access. All users
should have the same set of rights for a given access and all should be
able to alter the ACL on a file.
> 
> I'm currently mostly care about 1) and 3) to find out what is actually possible.
> also I'm currently doesn't care much about locking and parallel access to an inode,
> while changing it's acl. (I'm new to kernel development and first need to find out what of this
> stuff is needed)

i'm new here too.
> 
> I think it would be a good idea to just have one lsm that handle different kind of ACLS,
> but after a quick look at your kernel module code, there're some basic changes needed.
> 
> The main thing, I want to avoid is that we need any mapping of kernel acls to the NTACLS
> provided by samba. So the best thing for this is to just use NTACLS in the kernel, or to have
> something, that can be mapped 1 to 1 with loosing information.
> 
> the another idea is to use acls which use the same access bits, and use generic security identifier
> ( don't mean NT SID's hear)
as said above, ngacl supports the full range of nt access bits.
> 
> so maybe to have a
> struct security_identifier {
> 	enum {UID_T, DOM_SID, FOO } level;
> 	union {
> 		uid_t uid;
> 		struct dom_sid;
> 		struct foo;
> 	} u;
> };
> 
> and also have security_token's with this generic security_identifier
> 
> also the NTACLS have SACL's and DACL's we need to store whatevery a windows client wants us to
> store, and if possible use this information in the same way the client would expect it.
I think you should only store what you can interpert afterwards.
Anything else can be misleading for the user.
> 
> Do you have any ideas, how we could solve your and our problem, in one module?
> 
I think the main difference is the approach. If you implement ntacl-lsm
this way, only cifs-clients gain finer grained access control. 

chris



More information about the samba-technical mailing list