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

[L.A. Walsh]

On 12/12/2013 10:13 AM, Jeremy Allison wrote:
> On Wed, Dec 11, 2013 at 11:13:21PM -0800, L.A. Walsh wrote:
>   
>> I upgraded a few things on my system and have noticed a problem.
>>
>> I saved a file from Win7 -> samba share (using XFS)
>>
>> With the file was saved "security.NTACL" (and 2 other xattrs).
>>
>> I wanted to work on the file on a different partition
>> also using XFS.  The "mv" operation displayed an error that
>> the "security.NTACL" xattr was not able to be set on the
>> destination (permission denied).
>>
>> I also found doing a 'cp' from "theFile" => "thefile2"
>> silently stripped the 'security.NTACL'.
>>
>> Is it intentional that NTACLs should be so easily stripped
>> off by normal copy/move operations?
>>
>> I think, at issue, is that samba shouldn't use a 'root-priv-only'
>> "security" xattr, to store an ***Application*** attribute.
>>     
>
> The problem is that if these attributes are there, Samba
> can make security decisions based on their contents
> (who owns the file etc.).
>   
----
    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.  

    More in support of your use of it, though, I'm wondering why I can't
access the "security" attribute on a file _I_ own on a system that only
has "discretionary security" (though I don't mind the "root" namespace 
being reserved), but with a security system that IS NOT running with a
mandatory access security policy (where security policies are mandated
by the site and are not "discretionary"), why is the security namespace
keeping the user from exercising "discretionary" control?

    I'd be fine w/samba using that space, if it didn't bring the problems
of losing the ACL so easily.  Aside from the hassle of losing the ACL, it
would seem to be a security flaw to so easily toss out an NTACL (without
even a warning in the case of "cp").
> So at least as far as Samba is concerned, these *are*
> root-priv-only security attributes.
>   
But samba is providing that security for Win-clients -- the information
in those ACL's is specific to a file-server application (samba).  They
are not linux-system security attributes.  On the linux system,
they are just another application data blob that is easily stripped (too
easily!)... 

Note -- I don't WANT to remove it -- I just want it to be copied along
with the file so if I move it between dirs, or copy it, the ACL will still
be there when I access it from Windows.

By placing it in the linux-security namespace, it hinders it's usefulness.

Why can't samba identify the owner from the UID -- in my case, the UID
mapped to a domain login (the server is the PDC).

What would be lost by placing it in the USER xattr namespace?

Question -- has the namespace changed recently?  Or is some other util
just up and deciding users can't copy their own xattrs on their own files?

I.e. maybe some other util or lib is, _now_, prohibiting access where it
used to be allowed, and that's why I am seeing the messages now.(?)

Hopefully you can see this is a brewing problem...