[NT ACLS] Using the security.* namespace for NTACL considered improper
simo
I was following discussions on #samba-technical today and it came up
that we have started using security.NTACL as the namespace where to
store NT ACLs.
Talking with Christoph Hellwig he said that security.* should *not* be
used as it is reserved for LSM modules (like SeLinux).
Looking at man 5 attr this is briefly hinted indeed, and after further
discussion it became clear that we should used the trusted.* namespace
instead as this is what the man page says about it:
Trusted extended attributes are visible and accessible only
to processes that have the CAP_SYS_ADMIN capability (the super
user usually has this capability). Attributes in this class
are used to implement mechanisms in user space (i.e., outside
the kernel) which keep information in extended attributes to
which ordinary processes should not have access.
I think we should comply, and start moving NTACL to from security.NTACL
to trusted.NTACL as soon as possible, before it get widely used.
What do you think ?
Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer <si...@samba.org>
Principal Software Engineer at Red Hat, Inc. <si...@redhat.com>
Jeremy Allison
> Tridge, Jeremy,
> I was following discussions on #samba-technical today and it came up
> that we have started using security.NTACL as the namespace where to
> store NT ACLs.
>
> Talking with Christoph Hellwig he said that security.* should *not* be
> used as it is reserved for LSM modules (like SeLinux).
>
> Looking at man 5 attr this is briefly hinted indeed, and after further
> discussion it became clear that we should used the trusted.* namespace
> instead as this is what the man page says about it:
>
> Trusted extended attributes are visible and accessible only
> to processes that have the CAP_SYS_ADMIN capability (the super
> user usually has this capability). Attributes in this class
> are used to implement mechanisms in user space (i.e., outside
> the kernel) which keep information in extended attributes to
> which ordinary processes should not have access.
>
>
> I think we should comply, and start moving NTACL to from security.NTACL
> to trusted.NTACL as soon as possible, before it get widely used.
>
> What do you think ?
Raise a "blocker" bug in 3.5.0 to make sure we don't
ship a production release with this. Once we've shipped
there's no going back.
I'll make the change to "trusted.*" in the code, and
attach the change to the bug.
Jeremy.
Andrew Bartlett
> Tridge, Jeremy,
> I was following discussions on #samba-technical today and it came up
> that we have started using security.NTACL as the namespace where to
> store NT ACLs.
>
> Talking with Christoph Hellwig he said that security.* should *not* be
> used as it is reserved for LSM modules (like SeLinux).
>
> Looking at man 5 attr this is briefly hinted indeed, and after further
> discussion it became clear that we should used the trusted.* namespace
> instead as this is what the man page says about it:
>
> Trusted extended attributes are visible and accessible only
> to processes that have the CAP_SYS_ADMIN capability (the super
> user usually has this capability). Attributes in this class
> are used to implement mechanisms in user space (i.e., outside
> the kernel) which keep information in extended attributes to
> which ordinary processes should not have access.
>
>
> I think we should comply, and start moving NTACL to from security.NTACL
> to trusted.NTACL as soon as possible, before it get widely used.
>
> What do you think ?
I don't think we should change - the hope is that at some point that
kernels (maybe not the vanilla linux kernel) will read this attribute
and interpret it like NFSv4 ACLs (I presume) and POSIX ACLs that are
already.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
Volker Lendecke
> > I think we should comply, and start moving NTACL to from security.NTACL
> > to trusted.NTACL as soon as possible, before it get widely used.
> >
> > What do you think ?
>
> ship a production release with this. Once we've shipped
> there's no going back.
>
> I'll make the change to "trusted.*" in the code, and
> attach the change to the bug.
We'll have to pull back all 3.3 and 3.4 installations as
well.
Why not leave it as it is. How likely is it that a Linux(!)
kernel module conflicts with a name NTACL, except for the
very purpose to interoperate with Samba?
Volker
Jeremy Allison
> On Tue, Jan 19, 2010 at 12:10:19PM -0800, Jeremy Allison wrote:
> > > I think we should comply, and start moving NTACL to from security.NTACL
> > > to trusted.NTACL as soon as possible, before it get widely used.
> > >
> > > What do you think ?
> >
> > Raise a "blocker" bug in 3.5.0 to make sure we don't
> > ship a production release with this. Once we've shipped
> > there's no going back.
> >
> > I'll make the change to "trusted.*" in the code, and
> > attach the change to the bug.
>
> We'll have to pull back all 3.3 and 3.4 installations as
> well.
Do you know of any production sites that are using this ?
The modules are still marked experimental, so I'm not aware
of any real use out there. Might be wrong though. Anyone out
there using vfs_acl_xattr please chime in. We'd have to write a
'net acl migrate' command to rename these attributes.
I'd forgotten this module shipped in 3.3.x and beyond (I've
been fixing it up so much for 3.5.0 that I'd forgotten what
the changes were based on :-).
> Why not leave it as it is. How likely is it that a Linux(!)
> kernel module conflicts with a name NTACL, except for the
> very purpose to interoperate with Samba?
Probably not. Hmmm. As we do have shipping code out there,
this is much more difficult than I originally thought.
Comments from users would be appreciated.
Jeremy.
Jeremy Allison
> On Tue, Jan 19, 2010 at 12:10:19PM -0800, Jeremy Allison wrote:
> >
> > Once we've shipped there's no going back.
> >
> well.
Thinking about this some more (you're getting this in realtime :-).
Simo - we've already shipped using this xattr. It's almost
impossible to make this change now, sorry.
Working users always trump "correctness" every time, I'm
afraid.
Jeremy.
Volker Lendecke
> Do you know of any production sites that are using this ?
> The modules are still marked experimental, so I'm not aware
> of any real use out there. Might be wrong though. Anyone out
> there using vfs_acl_xattr please chime in. We'd have to write a
> 'net acl migrate' command to rename these attributes.
Well, that wouldn't work in the field. What about data on
tape?
Volker
Jeremy Allison
Yes, you're right. Working users out there take precedence.
Jeremy.
simo
Do we have any ?
Jeremy Allison
> On Tue, 2010-01-19 at 12:42 -0800, Jeremy Allison wrote:
> > On Tue, Jan 19, 2010 at 09:40:28PM +0100, Volker Lendecke wrote:
> > > On Tue, Jan 19, 2010 at 12:29:52PM -0800, Jeremy Allison wrote:
> > > > Do you know of any production sites that are using this ?
> > > > The modules are still marked experimental, so I'm not aware
> > > > of any real use out there. Might be wrong though. Anyone out
> > > > there using vfs_acl_xattr please chime in. We'd have to write a
> > > > 'net acl migrate' command to rename these attributes.
> > >
> > > Well, that wouldn't work in the field. What about data on
> > > tape?
> >
> > Yes, you're right. Working users out there take precedence.
>
> Do we have any ?
I do know of OEMs planning to use this, not sure how
many actually do right now.
tri...@samba.org
> Talking with Christoph Hellwig he said that security.* should *not* be
> used as it is reserved for LSM modules (like SeLinux).
As I mentioned on IRC (sending here so others can see it), the
original reason for choosing security.* was that it was intended that
we eventually implement a LSM module that understands these
ACLs. Interpreting them in smbd was a stop-gap measure.
We haven't actually built the LSM, but for secure ACLs we really
should. Having ACLs only interpreted in user space is always a
suboptimal solution, especially with mixtures of local login, NFS and
SMB access.
Cheers, Tridge
Volker Lendecke
Have you seen the number of bug reports that came in because
we accidentially broke access for Win98? You never know who
is lurking out there :-)
Volker
Björn Jacke
> > Do we have any ?
>
> many actually do right now.
I never heard or read of anyone using it expect for testing purposes. And
vfs_acl_xattr(8) states: "Please note that this module is experimental!". I
think "working users" is not (yet) a strong argument not to move the name
space.
Björn
Stefan (metze) Metzmacher
> Tridge, Jeremy,
> I was following discussions on #samba-technical today and it came up
> that we have started using security.NTACL as the namespace where to
> store NT ACLs.
>
> used as it is reserved for LSM modules (like SeLinux).
>
> discussion it became clear that we should used the trusted.* namespace
> instead as this is what the man page says about it:
>
> Trusted extended attributes are visible and accessible only
> to processes that have the CAP_SYS_ADMIN capability (the super
> user usually has this capability). Attributes in this class
> are used to implement mechanisms in user space (i.e., outside
> the kernel) which keep information in extended attributes to
> which ordinary processes should not have access.
>
>
> to trusted.NTACL as soon as possible, before it get widely used.
>
> What do you think ?
With trusted.* we need a become_root() each time we want to read the
security descriptor.
I think security.* is better because in future someone can implement
a kernel module for them, there's already a start of such a module in
the lorikeet svn tree.
metze
Jeremy Allison
> simo schrieb:
> > Tridge, Jeremy,
> > I was following discussions on #samba-technical today and it came up
> > that we have started using security.NTACL as the namespace where to
> > store NT ACLs.
> >
> > Talking with Christoph Hellwig he said that security.* should *not* be
> > used as it is reserved for LSM modules (like SeLinux).
> >
> > Looking at man 5 attr this is briefly hinted indeed, and after further
> > discussion it became clear that we should used the trusted.* namespace
> > instead as this is what the man page says about it:
> >
> > Trusted extended attributes are visible and accessible only
> > to processes that have the CAP_SYS_ADMIN capability (the super
> > user usually has this capability). Attributes in this class
> > are used to implement mechanisms in user space (i.e., outside
> > the kernel) which keep information in extended attributes to
> > which ordinary processes should not have access.
> >
> >
> > I think we should comply, and start moving NTACL to from security.NTACL
> > to trusted.NTACL as soon as possible, before it get widely used.
> >
> > What do you think ?
>
> With trusted.* we need a become_root() each time we want to read the
> security descriptor.
We have to do that with security.* also - in fact we
already do :-).
Jeremy.
simo
All we need for either security.* or trusted.* is SYS_CAP_ADMIN, so we
could avoid become_root() if letting the process retain SYS_CAP_ADMIN
does not have other unintended consequences.
Matthieu Patou
root@ares:/tmp# setfattr -n "trusted.pouet" -v "p" p
root@ares:/tmp# getfattr -d -m "" p
# file: p
trusted.pouet="p"
root@ares:/tmp# setfattr -n "security.pouet" -v "p" p
root@ares:/tmp# getfattr -d -m "" p
# file: p
security.pouet="p"
trusted.pouet="p"
mat@ares:~$ getfattr -d -m "" /tmp/p
getfattr: Removing leading '/' from absolute path names
# file: tmp/p
security.pouet="p"
Clearly me as a simple user I can read securiy.* but not trusted.*.
Matthieu.
>
>
Stefan (metze) Metzmacher
> could avoid become_root() if letting the process retain SYS_CAP_ADMIN
> does not have other unintended consequences.
Extended security attributes
The security attribute namespace is used by kernel security
modules, such as Security Enhanced
Linux. Read and write access permissions to security attributes
depend on the policy implemented
for each security attribute by the security module. When no
security module is loaded, all pro‐
cesses have read access to extended security attributes, and
write access is limited to processes
that have the CAP_SYS_ADMIN capability.
CAP_SYS_ADMIN is only needed for writing not reading and that is the
difference between security. and trusted.
metze
simo
> Extended security attributes
> The security attribute namespace is used by kernel
> security
> modules, such as Security Enhanced
> Linux. Read and write access permissions to security
> attributes
> depend on the policy implemented
> for each security attribute by the security module. When
> no
> security module is loaded, all pro‐
> cesses have read access to extended security attributes, and
> write access is limited to processes
> that have the CAP_SYS_ADMIN capability.
>
> CAP_SYS_ADMIN is only needed for writing not reading and that is the
> difference between security. and trusted.
Yes, every time we need to write the ACLs, at the moment, we need to use
become_root(), but we don't really need to be uid 0 to write. All we
need is to have CAP_SYS_ADMIN.
What I am saying is that unless retaining CAP_SYS_ADMIN has unintended
consequences in other parts of the code, we could get rid of the need to
call become_root() to write ACLs (or to read them if they were moved to
trusted.*, which won't happen at the moment).
become_root() comes with a cost and a risk, so removing it, where
possible looks like a very good idea.