where/how is 'xattr' type=security enforced? (security attr stripped?)

where/how is 'xattr' type=security enforced? (security attr stripped?)

[Linda Walsh]

I got a weird message that I've never seen before -- nothing
life shattering, just a curiosity that I thought shouldn't happen.


I stored a file in my /home partition FROM a Win7 client
via samba 3.6.16.

With that file were also stored xattrs:

DOSATTRIB, SAMBA_PAI and NTACL.  Since linux is the 'server',
These are all likely set via samba.

To work on the file more, I wanted to move it
to /tmp.

I use mv:
> mv  /home/law/tmp/oVars.pm /tmp
mv: setting attribute ‘security.NTACL’ for ‘security.NTACL’: Operation not permitted

"I" was the owner of the file (same UID is resolved for NT-user & local user) and
local user is in group that file was stored under.

I am trying to figure out where this message came from, as 'mv' doesn't
do any access enforcement based on the 'xattr' name field.

The impact of this is I can't move the file without losing security
which is automatically stripped.

Trying to *copy* the file within the same directory also results
in the security xattr being stripped -- but ***silently***.

So what was responsible for prohibiting the moving the the xfs 'xattr'?

My thoughts on this are that if I, as a user can write such a file
(to my home dir in this case) and the attributes are created (indirectly)
by "me" when I create the file, I should also be able to move the file
**intact** with the NTACL maintained.

In both cases, the file system types are the same (xfs).  The creator
and the mover are the same UID.  Both file systems can be accessed
via my Win7 Client.

So anyone know why this fails or why it is silently stripped on a
"cp"?

Thanks...(maybe a kernel bug?)


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

Re: where/how is 'xattr' type=security enforced? (security attr stripped?)

[Dave Chinner]

On Mon, Dec 09, 2013 at 04:05:41PM -0800, Linda Walsh wrote:
> I got a weird message that I've never seen before -- nothing
> life shattering, just a curiosity that I thought shouldn't happen.
> 
> 
> I stored a file in my /home partition FROM a Win7 client
> via samba 3.6.16.
> 
> With that file were also stored xattrs:
> 
> DOSATTRIB, SAMBA_PAI and NTACL.  Since linux is the 'server',
> These are all likely set via samba.
> 
> To work on the file more, I wanted to move it
> to /tmp.
> 
> I use mv:
> >mv  /home/law/tmp/oVars.pm /tmp
> mv: setting attribute ‘security.NTACL’ for ‘security.NTACL’: Operation not permitted

You need root permissions to set security namespace attributes.

$setfattr -n security.NTACL -v foobarchucky /mnt/test/foo
setfattr: /mnt/test/foo: Operation not permitted
$ sudo setfattr -n security.NTACL -v foobarchucky
/mnt/test/foo
$ getfattr -n security.NTACL /mnt/test/foo
getfattr: Removing leading '/' from absolute path names
# file: mnt/test/foo
security.NTACL="foobarchucky"

$

[ On a side note, there's some sooper seekrit voodoo there in
getfattr.  I feel that my systems are so much more secure knowing
that getfattr is protecting me from \something/ so dangerous it
can't possibly be worked around with sed or --absolute-names. ]

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: where/how is 'xattr' type=security enforced? (security attr stripped?)

[LA Walsh]

On 12/9/2013 9:52 PM, Dave Chinner wrote:
> You need root permissions to set security namespace attributes.
----
I knew that about the root namespace, but the security namespace
isn't as well documented.

I'd *hoped* for something that made 'sense' -- like the owner
being able to set/change, at least some of them, like mode bits.

I know this isn't a problem, actually "in XFS", but more
in how it is used.  Thinking out loud...if you'll bare
w/me:

Since it's an NTACL, on a file created and owned me, in
a directory that I 'own' the ACL for (as I'm the owner
of the file and the dir it is in), it seems Samba is trying
to follow NT rules in placing the ACL w/the file.

But then the linux utils come along and change the rules
and   strip off the NT-ACL,  when the file is copied or
when it is moved to a different partition (also XFS).

What about the posix ACL's?  Aren't they in the security
section as well?  Do they get stripped off whenever
a copy is made or the file is moved to another XFS
file system?

The NTACL was set on the file because it inherited permissions
under 'NT' rules.  Shouldn't I be able to copy or move the
file (presuming I am the owner and directory owner, etc..).
What about posix ACL's?

It seems to me, that the security section of an ACL should be
(assuming you have the normal, discretionary access system
on linux), should be movable and settable by the file owner.

Under a different security setup (say with mandatory access
rules -- like under SMACK or Flask) it would be a different
matter, but it seems a bit odd to be stripping ACL's from
a file just because it is copied/moved...


> [ On a side note, there's some sooper seekrit voodoo ....
yeah, vaguely remember that...

FWIW -- I've never seen a message like I'm getting now...
so don't know if it is a change in Samba/coreutils or the
kernel (all of which have changed recently in installing
a new suse release for most things)...


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