Re: Security issue - storing NTACL's in non-NT-security-namespace

Re: Security issue - storing NTACL's in non-NT-security-namespace

[L.A. Walsh]

On 12/13/2013 2:53 AM, Christoph Hellwig wrote:
> On Fri, Dec 13, 2013 at 12:39:40AM -0800, L.A. Walsh wrote:
>   
>>    Does it have to be under a "namespace" that gets *stripped*
>> as soon as the file is copied or "mv'd to another
>> samba share (i.e. the partition it was moved to is shared with the
>> same permissions as the first one.
>>     
>
> Attributes never get "stripped", they simple don't get copied unless
> explicit action is taken to do so.  Setting trusted attributes up on a
> new file will of course rely privilegues, exactly for the reasons
> Jeremy pointed out.
>   
----

Stripping is the default action when copying or moving unless you
take some *non-default* (and unspecified) action, AND providing you
even know they are there..

The same is NOT true for the *real* xfs-ACLS -- which are
copied w/o issue.


Example,

testfile.txt (saved via win7 as a normal user in my Doc dir:
(letter on left is my abbrieviation

  Ishtar:law/Documents> attr -l testfile.txt
U  Attribute "DOSATTRIB" has a 56 byte value for testfile.txt
R  Attribute "SGI_ACL_FILE" has a 64 byte value for testfile.txt
U  Attribute "SAMBA_PAI" has a 31 byte value for testfile.txt
S  Attribute "NTACL" has a 328 byte value for testfile.txt      

Then copy using "explicit action" (-a) to save extended attributes:

 Ishtar:law/Documents> cp -a testfile.txt testcopy.txt
 Ishtar:law/Documents> attr -l testcopy.txt
   Attribute "DOSATTRIB" has a 56 byte value for testcopy.txt
   Attribute "SGI_ACL_FILE" has a 64 byte value for testcopy.txt
   Attribute "SAMBA_PAI" has a 31 byte value for testcopy.txt

Now NOTE: if I don't use "explicit action" (-a) in my copy:

 Ishtar:law/Documents> /usr/bin/cp testfile.txt testcopy.txt
 Ishtar:law/Documents> attr -l testcopy.txt                
   Attribute "SGI_ACL_FILE" has a 76 byte value for testcopy.txt

ONLY the root-namespace ACL is save  -- the user and security
attributes are striped.

If I try "mv"ing the -- on the same volume, I am "fine" (attributes
don't get dropped).

But if I cross a file boundary (to another XFS partition):

 Ishtar:law/Documents> mv testfile.txt /Share/CPAN/
   mv: setting attribute ‘security.NTACL’ for ‘security.NTACL’:
       Operation not permitted
 Ishtar:law/Documents> attr -l /Share/CPAN/testfile.txt
   Attribute "DOSATTRIB" has a 56 byte value for /Share/CPAN/testfile.txt
   Attribute "SGI_ACL_FILE" has a 64 byte value for
    /Share/CPAN/testfile.txt
   Attribute "SAMBA_PAI" has a 31 byte value for /Share/CPAN/testfile.txt


Only the Security attribute is stripped.  the root namespace is copyable
by a user


Note.  I saw this message for the 1st time, last week (the permission
message on the move).  Do you have any idea what might have caused
such a change?

Did Samba changed namespaces, or is some library refusing to copy this
or maybe a kernel change?



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Security issue - storing NTACL's in non-NT-security-namespace

[Jeremy Allison]

On Fri, Dec 13, 2013 at 01:32:12PM -0800, L.A. Walsh wrote:
> Now NOTE: if I don't use "explicit action" (-a) in my copy:
> 
> Ishtar:law/Documents> /usr/bin/cp testfile.txt testcopy.txt
> Ishtar:law/Documents> attr -l testcopy.txt
> Attribute "SGI_ACL_FILE" has a 76 byte value for testcopy.txt
> 
> ONLY the root-namespace ACL is save  -- the user and security
> attributes are striped.

What is the namespace for SGI_ACL_FILE ?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Security issue - storing NTACL's in non-NT-security-namespace

[L.A. Walsh]

On 12/13/2013 2:08 PM, Jeremy Allison wrote:
> On Fri, Dec 13, 2013 at 01:32:12PM -0800, L.A. Walsh wrote:
>   
>> Now NOTE: if I don't use "explicit action" (-a) in my copy:
>>
>> Ishtar:law/Documents> /usr/bin/cp testfile.txt testcopy.txt
>> Ishtar:law/Documents> attr -l testcopy.txt
>> Attribute "SGI_ACL_FILE" has a 76 byte value for testcopy.txt
>>
>> ONLY the root-namespace ACL is save  -- the user and security
>> attributes are striped.
>>     
>
> What is the namespace for SGI_ACL_FILE ?
>   
root


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Security issue - storing NTACL's in non-NT-security-namespace

[Dave Chinner]

On Fri, Dec 13, 2013 at 02:08:48PM -0800, Jeremy Allison wrote:
> On Fri, Dec 13, 2013 at 01:32:12PM -0800, L.A. Walsh wrote:
> > Now NOTE: if I don't use "explicit action" (-a) in my copy:
> > 
> > Ishtar:law/Documents> /usr/bin/cp testfile.txt testcopy.txt
> > Ishtar:law/Documents> attr -l testcopy.txt
> > Attribute "SGI_ACL_FILE" has a 76 byte value for testcopy.txt
> > 
> > ONLY the root-namespace ACL is save  -- the user and security
> > attributes are striped.
> 
> What is the namespace for SGI_ACL_FILE ?

That's XFS's on-disk name for a posix ACL, which are kept the root
namespace.  It's a file ACL, not a default ACL (which are named
SGI_ACL_DEFAULT), so it was placed there by the user after VFS
allowed it to be created.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: BTW - to xfs folk, 'security attr' doesn't seem very useful w/current copy policies

[L.A. Walsh]

On 12/13/2013 1:32 PM, L.A. Walsh wrote:
> On 12/13/2013 2:53 AM, Christoph Hellwig wrote:
> > On Fri, Dec 13, 2013 at 12:39:40AM -0800, L.A. Walsh wrote:
> >  
> >>    Does it have to be under a "namespace" that gets *stripped*
> >> as soon as the file is copied or "mv'd to another
> >> samba share (i.e. the partition it was moved to is shared with the
> >> same permissions as the first one.
> >
> > Attributes never get "stripped", they simple don't get copied unless
> > explicit action is taken to do so.  Setting trusted attributes up on a
> > new file will of course rely privilegues, exactly for the reasons
> > Jeremy pointed out.
-----
For what purpose?  As it stands the security namespace doesn't seem
very useful -- i.e. the 'root' attrs get copied and/or moved on a file
copy/rename which carries the access along with the file contents.

But I fail to see the usefulness in having a security namespace that
is dropped by default on copies or inter-partition moves.

Shouldn't it follow along and be copied much as are the root namespace
entries?

It gets really confusing if a "proxy service" (ex. file server)
for the user, stores attributes in that namespace thinking they will
somehow be useful when the user accesses the file w/o the proxy service --
i.e. as a normal file.

Was there a specific use-case for being able to tag files with security
attrs that can't be copied, moved or renamed except by root that wouldn't
better be served by signed or 'sealed' (encrypted) content?  For most
cases, it would seem that signing to detect tampering would be enough,
though I can think of cases where sealing to prevent knowledge of
who has what access would also be useful.

Something to think about before others try to use the security field to
store attrs they want kept with the content and not the inode.




_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: BTW - to xfs folk, 'security attr' doesn't seem very useful w/current copy policies

[Dave Chinner]

On Sun, Dec 15, 2013 at 06:21:52AM -0800, L.A. Walsh wrote:
> 
> 
> On 12/13/2013 1:32 PM, L.A. Walsh wrote:
> >On 12/13/2013 2:53 AM, Christoph Hellwig wrote:
> >> On Fri, Dec 13, 2013 at 12:39:40AM -0800, L.A. Walsh wrote:
> >>  >>    Does it have to be under a "namespace" that gets
> >*stripped*
> >>> as soon as the file is copied or "mv'd to another
> >>> samba share (i.e. the partition it was moved to is shared with the
> >>> same permissions as the first one.
> >>
> >> Attributes never get "stripped", they simple don't get copied unless
> >> explicit action is taken to do so.  Setting trusted attributes up on a
> >> new file will of course rely privilegues, exactly for the reasons
> >> Jeremy pointed out.
> -----
> For what purpose?  As it stands the security namespace doesn't seem
> very useful -- i.e. the 'root' attrs get copied and/or moved on a file
> copy/rename which carries the access along with the file contents.
> 
> But I fail to see the usefulness in having a security namespace that
> is dropped by default on copies or inter-partition moves.

So you want users with no privileges to be able to create and
modify security context imformation, such as selinux labels,
integrity hashes, etc? Really?

> Shouldn't it follow along and be copied much as are the root namespace
> entries?

There is no "root" attribute namespace that users can manipulate -
there is a "trusted" namespace for root users, but that's not what
you are talking about.  The VFS defined name spaces are:

	- user
	- security
	- trusted (requires CAP_SYS_ADMIN)
	- system

All of the other xattrs fall into these groups. e.g. posix acls:

	- system.posix_acl_access
	- system.posix_acl_default

What you are doing is conflating how XFS stores xattrs on disk with
user visible xattr namespaces. The two are not the same thing. The
VFS enforces access to the "trusted" namespace and posix ACLs,
security modules enforce access to their own attributes and
potentially restrict access to the entire security namespace.
Whatever remains is left up to the filesystem to decide access
rules.


Hence, cp as a user cannot copy trusted xattrs and certain security
attributes as a matter of principle, and some security modules only
allow security xattr write permission to CAP_SYS_ADMIN (e.g.
selinux), and hence cp as a user cannot read and/or write these
xattrs to put them on the newly copied file.

IOWs, how XFS stores them on disk is irrelevant to access
permissions that are enforced by layers above it...

> It gets really confusing if a "proxy service" (ex. file server)
> for the user, stores attributes in that namespace thinking they will
> somehow be useful when the user accesses the file w/o the proxy service --
> i.e. as a normal file.

That's never worked. xattrs are only meaningful to the application
that created them. Trying to manipulate those xattrs as a user
outside the context of the application is almost always going to
fail when special permissions are required by the application to
manipulate those xattrs.

> Was there a specific use-case for being able to tag files with security
> attrs that can't be copied, moved or renamed except by root that wouldn't
> better be served by signed or 'sealed' (encrypted) content?  For most
> cases, it would seem that signing to detect tampering would be enough,
> though I can think of cases where sealing to prevent knowledge of
> who has what access would also be useful.
> 
> Something to think about before others try to use the security field to
> store attrs they want kept with the content and not the inode.

Access to the security xattr namespace is entirely controlled by the
kernel security modules. If you want to use that namespace, you have
to follow whatever rules your currently loaded security module
enforces. That, in general, means that the only thing you can
guarantee is that the security xattr namespace requires
CAP_SYS_ADMIN for write access.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: usefulness of 'security attr' being non-copiable on discretionary access linux.

[LA Walsh]

On 12/15/2013 3:54 PM, Dave Chinner wrote:
>  default on copies or inter-partition moves.
>
> So you want users with no privileges to be able to create and
> modify security context imformation, such as selinux labels,
> integrity hashes, etc? Really?
----
    If they are running under a non-SElinux system where only 
*discretionary* access
is used, why not?  It's not like it would do any good.
>
>> Shouldn't it follow along and be copied much as are the root namespace
>> entries?
>
> There is no "root" attribute namespace that users can manipulate -
> there is a "trusted" namespace for root users, but that's not what
> you are talking about.  The VFS defined name spaces are:
----
    Sorry, I was going by this manpage, shipped by (it looks like) Gnu 
with their
xattr program:

XFS uses  2  disjoint  attribute  name  spaces  associated  with  every
filesystem  object.   They  are  the root and user address spaces.  The
root address space is accessible only to the superuser, and  then  only
by  specifying  a flag argument to the function call.  Other users will
not see or be able to modify attributes in the root address space.  The
user  address  space is protected by the normal file permissions mecha-
nism, so the owner of the file can decide who is  able  to  see  and/or
modify the value of attributes on any particular file.


>
> 	- user
> 	- security
> 	- trusted (requires CAP_SYS_ADMIN)
> 	- system
----
    Doesn't security also require CAP_SYS_ADMIN?


>
> All of the other xattrs fall into these groups. e.g. posix acls:
>
> 	- system.posix_acl_access
> 	- system.posix_acl_default
>
> What you are doing is conflating how XFS stores xattrs on disk with
> user visible xattr namespaces. The two are not the same thing.
----
    That's fine -- the virtual model != the physical model -- just like 
in almost every
other area.  ;-)

>  The
> VFS enforces access to the "trusted" namespace and posix ACLs,
> security modules enforce access to their own attributes and
> potentially restrict access to the entire security namespace.
> Whatever remains is left up to the filesystem to decide access
> rules.
>
>
> Hence, cp as a user cannot copy trusted xattrs and certain security
> attributes as a matter of principle, and some security modules only
> allow security xattr write permission to CAP_SYS_ADMIN (e.g.
> selinux), and hence cp as a user cannot read and/or write these
> xattrs to put them on the newly copied file.
-----
    I'm running with the "default" security (Discretionary -
mode bits + access lists + cap bits slowly supplanting need for root.



>
> IOWs, how XFS stores them on disk is irrelevant to access
> permissions that are enforced by layers above it...
>
>> It gets really confusing if a "proxy service" (ex. file server)
>> for the user, stores attributes in that namespace thinking they will
>> somehow be useful when the user accesses the file w/o the proxy service --
>> i.e. as a normal file.
>
> That's never worked. xattrs are only meaningful to the application
> that created them. 
----
NT attrs that are stored on a file server, _natively_ are the same
as local attrs.  Samba has traditionally tried to map as much of the
NT acl -> the native acl.  In this particular instance, an
unprivileged user (me) saved a file to their home directory.  Then as
an unprivileged user, I couldn't move the file without saving the NT
ACL -- which would still be desired (or needed) on any other exported
NT partition. 

I feel it is a a problem if a normal user can both create the ACL's
when accessing the share over samba but cannot directly move or create
such ACL's.  It it is like Windows, I could probably mount it via a 
loopback, and using the file system presented by samba and mounted
with CIFS (untested), but a user on a client (remote or local) should
have consistent access to the ACL that is stored on the file so they
can move, copy it or back it up.


> Trying to manipulate those xattrs as a user
> outside the context of the application is almost always going to
> fail when special permissions are required by the application to
> manipulate those xattrs.
-----
    They don't on NT-servers.  The native OS ACLS are pretty
much the same.  If I have an ACL on the file and move it, it
goes with the file.  Of course if the file is using a directory
default ACL, it gets whatever it gets in the new dir.

    File sensitivity flags are stored on NT to flag possibly unsafe
material (downloaded material from general internet, for example).

    The user can't set those labels directly, but they do get moved
by the system if the user moves or copies the file.


> Access to the security xattr namespace is entirely controlled by the
> kernel security modules. If you want to use that namespace, you have
> to follow whatever rules your currently loaded security module
> enforces. That, in general, means that the only thing you can
> guarantee is that the security xattr namespace requires
> CAP_SYS_ADMIN for write access.
It also appears the system namespace isn't visible unless you have that 
CAP set.  I.e. the manpage is correct in this regard.

====
As I tried to make clear -- this is a new behavior I'm seeing.  I've never
had attrs on my files that I, as the file 'owner' couldn't move around
to permitted locations.  As it is an ACL, my feeling is it should be
stored in the same way the posix acls are -- which are copyable.






_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: usefulness of 'security attr' being non-copiable on discretionary access linux.

[Dave Chinner]

On Sun, Dec 15, 2013 at 06:20:20PM -0800, LA Walsh wrote:
> On 12/15/2013 3:54 PM, Dave Chinner wrote:
> > default on copies or inter-partition moves.
> >
> >So you want users with no privileges to be able to create and
> >modify security context imformation, such as selinux labels,
> >integrity hashes, etc? Really?
> ----
>    If they are running under a non-SElinux system where only
> *discretionary* access
> is used, why not?  It's not like it would do any good.
> >
> >>Shouldn't it follow along and be copied much as are the root namespace
> >>entries?
> >
> >There is no "root" attribute namespace that users can manipulate -
> >there is a "trusted" namespace for root users, but that's not what
> >you are talking about.  The VFS defined name spaces are:
> ----
>    Sorry, I was going by this manpage, shipped by (it looks like)
> Gnu with their
> xattr program:
> 
> XFS uses  2  disjoint  attribute  name  spaces  associated  with  every
> filesystem  object.   They  are  the root and user address spaces.  The
> root address space is accessible only to the superuser, and  then  only
> by  specifying  a flag argument to the function call.  Other users will
> not see or be able to modify attributes in the root address space.  The
> user  address  space is protected by the normal file permissions mecha-
> nism, so the owner of the file can decide who is  able  to  see  and/or
> modify the value of attributes on any particular file.

Note the name of the man page:

ATTR(1) XFS Compatibility API

The fact there is a utility that lets you access the XFS on-disk
xattr space does not mean other tools actually access those
namespaces directly.

Indeed, have you looked at what attr does when it writes an
attribute into the "root" namespace in XFS?

$ sudo strace attr -R -s blah -V grotfuddink foo
....
lsetxattr("foo", "trusted.blah", "grotfuddink", 11, 0) = 0
....

It writes it into the "trusted" VFS xattr namespace which means it
knows *nothing* about how XFS stores it's xattrs on disk.

> >	- user
> >	- security
> >	- trusted (requires CAP_SYS_ADMIN)
> >	- system
> ----
>    Doesn't security also require CAP_SYS_ADMIN?

I've already answered that question:

> >Hence, cp as a user cannot copy trusted xattrs and certain security
> >attributes as a matter of principle, and some security modules only
> >allow security xattr write permission to CAP_SYS_ADMIN (e.g.
> >selinux), and hence cp as a user cannot read and/or write these
> >xattrs to put them on the newly copied file.
> -----
>    I'm running with the "default" security (Discretionary -
> mode bits + access lists + cap bits slowly supplanting need for root.

So, did you turn the distro default selinux config off?

> >permissions that are enforced by layers above it...
> >
> >>It gets really confusing if a "proxy service" (ex. file server)
> >>for the user, stores attributes in that namespace thinking they will
> >>somehow be useful when the user accesses the file w/o the proxy service --
> >>i.e. as a normal file.
> >
> >That's never worked. xattrs are only meaningful to the application
> >that created them.
> ----
> NT attrs that are stored on a file server, _natively_ are the same
> as local attrs.  Samba has traditionally tried to map as much of the
> NT acl -> the native acl.  In this particular instance, an
> unprivileged user (me) saved a file to their home directory.  Then as
> an unprivileged user, I couldn't move the file without saving the NT
> ACL -- which would still be desired (or needed) on any other exported
> NT partition.

You missed what I said completely. You didn't create the NT attr,
Samba did it on your behalf. Samba - the aplication that owns the
xattr - has higher privileges than you do, and so it can do things
you can't. Like manage attributes in the security namespace.

> I feel it is a a problem if a normal user can both create the ACL's
> when accessing the share over samba but cannot directly move or create
> such ACL's. 

Just because you own the file, it doesn't mean you own or can access
all the xattrs on it the file.

> >Access to the security xattr namespace is entirely controlled by the
> >kernel security modules. If you want to use that namespace, you have
> >to follow whatever rules your currently loaded security module
> >enforces. That, in general, means that the only thing you can
> >guarantee is that the security xattr namespace requires
> >CAP_SYS_ADMIN for write access.
> It also appears the system namespace isn't visible unless you have
> that CAP set.  I.e. the manpage is correct in this regard.
> 
> ====
> As I tried to make clear -- this is a new behavior I'm seeing.  I've never
> had attrs on my files that I, as the file 'owner' couldn't move around
> to permitted locations.  As it is an ACL, my feeling is it should be
> stored in the same way the posix acls are -- which are copyable.

Then something above the filesystem has changed. We haven't changed
anything to do with who or how xattrs are stored or used in XFS for
a long time.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: usefulness of 'security attr' being non-copiable on discretionary access linux.

[LA Walsh]

On 12/15/2013 7:02 PM, Dave Chinner wrote:
> It writes it into the "trusted" VFS xattr namespace which means it
> knows *nothing* about how XFS stores it's xattrs on disk.
----

I never said it was correct, Dave.  At best, I thought it might have
represented some state in the past.


>> -----
>>    I'm running with the "default" security (Discretionary -
>> mode bits + access lists + cap bits slowly supplanting need for root.
> 
> So, did you turn the distro default selinux config off?
----
Suse ships AppArmor enabled by default, not selinux.

I run my own kernel from kernel.org sources.  (Suse doesn't
support booting directly  from disk, and /usr is expected
to be mounted when the OS starts coming up (they put mount in
/usr/bin now and a symlink in /bin pointing to /usr/bin.


> You missed what I said completely. You didn't create the NT attr,
> Samba did it on your behalf. Samba - the aplication that owns the
> xattr - has higher privileges than you do, and so it can do things
> you can't. Like manage attributes in the security namespace.
---

I didn't miss it -- I was talking about user-proxies.  The point of
my running a linux server as a Domain Controller is that I have 1 point
of security on my net -- the server, and whether I log in to a client
or the server, I "should" (conceptually) have access to the same files.

If I ssh from the client to the server, I see a message in messages:

    sshd accepted public key for Domain\\linda from [station]...

Samba provides user and group name resolution and security for the
server.


>> ====
>> As I tried to make clear -- this is a new behavior I'm seeing.  I've never
>> had attrs on my files that I, as the file 'owner' couldn't move around
>> to permitted locations.  As it is an ACL, my feeling is it should be
>> stored in the same way the posix acls are -- which are copyable.
> 
> Then something above the filesystem has changed. We haven't changed
> anything to do with who or how xattrs are stored or used in XFS for
> a long time.
----
	Neither the kernel nor xfs were high on my list of
candidates.
> 
> Cheers,
---
and felicitations!...

linda

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs