[NT ACLS] Using the security.* namespace for NTACL considered improper

[simo]

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 ?

Simo.

[Jeremy Allison]

Post by simo
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
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.

[Volker Lendecke]

Post by Jeremy Allison

Post by simo
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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100119/da1afbf8/attachment.pgp>

[Jeremy Allison]

Post by Volker Lendecke

Post by Jeremy Allison

Post by simo
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 :-).

Post by Volker Lendecke
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.

[Volker Lendecke]

Post by Jeremy Allison
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100119/4816e4af/attachment.pgp>

[Jeremy Allison]

Post by Volker Lendecke

Post by Jeremy Allison
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.

Jeremy.

[simo]

Post by Jeremy Allison

Post by Volker Lendecke

Post by Jeremy Allison
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 ?

Simo.

[Jeremy Allison]

Post by simo

Post by Jeremy Allison

Post by Volker Lendecke

Post by Jeremy Allison
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.

[Björn Jacke]

Post by Jeremy Allison

Post by simo
Do we have any ?

I do know of OEMs planning to use this, not sure how
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100119/d4f3829d/attachment.pgp>

[Volker Lendecke]

Post by simo

Post by Jeremy Allison

Post by Volker Lendecke

Post by Jeremy Allison
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 ?

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

[Jeremy Allison]

Post by Volker Lendecke

Once we've shipped there's no going back.

We'll have to pull back all 3.3 and 3.4 installations as
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.

[Andrew Bartlett]

Post by simo
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100120/f82e9dda/attachment.pgp>

[tridge]

Hi Simo,

Post by simo
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

[Stefan (metze) Metzmacher]

Post by simo
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
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.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100120/4726af36/attachment.pgp>

[Jeremy Allison]

Post by Stefan (metze) Metzmacher

Post by simo
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
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]

Post by Jeremy Allison

Post by Stefan (metze) Metzmacher

Post by simo
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
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 :-).

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.

Simo.

[Stefan (metze) Metzmacher]

Post by simo

Post by Jeremy Allison

Post by Stefan (metze) Metzmacher

Post by simo
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
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 :-).

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100120/cd18e5b2/attachment.pgp>

[simo]

Post by Stefan (metze) Metzmacher
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.

Simo.

[Matthieu Patou]

Post by Jeremy Allison

Post by Stefan (metze) Metzmacher

Post by simo
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
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 :-).

I am not sure that reading security.* imply to be root ie.

root at ares:/tmp# setfattr -n "trusted.pouet" -v "p" p
root at ares:/tmp# getfattr -d -m "" p
# file: p
trusted.pouet="p"

root at ares:/tmp# setfattr -n "security.pouet" -v "p" p
root at ares:/tmp# getfattr -d -m "" p
# file: p
security.pouet="p"
trusted.pouet="p"

mat at 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.