[Toybox] Squinting at LSM support in cp.

James McMechan james_mcmechan at hotmail.com
Wed Jul 15 22:26:50 PDT 2015


For some odd reason the reply got routed to rob at landley.net not the toybox list...

> Date: Tue, 14 Jul 2015 19:31:43 -0500
> From: rob at landley.net
> To: enh at google.com
> CC: toybox at lists.landley.net
> Subject: Re: [Toybox] Squinting at LSM support in cp.
>
> On 07/14/2015 03:24 PM, enh wrote:
>> On Fri, Jul 10, 2015 at 11:33 AM, Rob Landley <rob at landley.net> wrote:
>>> Alas I have _no_ idea how to explain that last part concisely in the
>>> help text. I'm also aware --no-preserve=context seems like it should
>>> strip security context and if people want to argue for that instead, I'm
>>> going to rant about how this entire mess is badly designed and there
>>> should already be some xattr version of chmod -R that does a regex
>>> search and replace on extended attribute key/value pairs, and that if
>>> such a tool doesn't already exist to be copied then this LSM stuff
>>> doesn't get used by non-bureaucrats, and cp probably isn't that tool
>>> although maybe it can share infrastructure with it, and then I'd ask
>>> somebody to explain to me what cp --attributes-only is for exactly?
>>
>> there's no chmod/chown equivalent in the literal sense, but
>> restorecon(8) is probably the closest. basically you don't trust
>> arbitrary operations, and you have a tool that applies the correct
>> labels based on its configuration. (so you have to get the
>> configuration right, but you can largely ignore arbitrary fs
>> modifications.)
>>
I seem to note a chsmack command
 
>> note also that most processes can't set a file's label, and not having
>> a label is fail-safe in the sense of "that gets you nothing".
>
> Ok, so labels never _restrict_ access to files, they just grant extra
> things to them? ("I could do X with this file/directory if it wasn't for
> the label on it" does not ever apply?)
>
> That would make the race conditions a lot less of an issue, yes.
 
Yes it would make it simpler, alas I expect this is another choose two of three
reliable, secure, simple.
 
I seem to remember that yes you can restrict permissions via labels
e.g. the section that talks about "These rules are only consulted if access would otherwise be permitted"
would imply that it is only checked when you already have permission from the system.

So it looks like it can only disallow, I seem to remember there was a debate about this when MAC went in
that permissive actions should not be permitted by the MAC only disallow...

That we have at least two different security implementations that both seem to assume you will never
do anything outside of their particular sandbox does not help, along with attributes being used for 
every different kind of metadata and all of them assuming that their use is the only important one
I seem to remember ACLs are also implemented in xattrs so are alternate data streams, so you have one
set of assumptions that the data is small zero terminated string that can be read atomically and other
uses where it may be a named mulit-gigabyte binary blob.

As I recall XFS, NTFS, HFS+, Reiserfs4 all support unlimited size meta data in the xattrs
the ext[234] series had I think something like a one block limitation which could easily be hit and I don't know
about the other filesystems.

Thinking about it having separate parsers based on the name of each xattr for each security mode to see if
it adds or removes permissions for !simple but reliable and secure
or just setting permissions to 700 copying over the contents and xattrs 
and then changing to the correct permissions !reliable but simple and secure
or sticking the xattrs on after copying and setting the permissions !secure but simple and reliable...

I would pick #2 since it looks like it should mostly work and when you have weird exceptions it would be weird...

On the history side I first ran into weirdness like this years ago ~1989? with HP's CDF Context Dependant Files
see 5.9 Oddities and Dubious Ideas ->  5.9.2 Context-Dependent Files
http://docstore.mik.ua/orelly/networking/puis/ch05_09.htm

I get the feeling that the triangular wheel has been reinvented again...

Personally I have never liked the out of band attempts to fix the fact you can't have user created groups or more than one group per file
I don't even configure my filesystems with xattr support unless I expect to need it, which has not occurred in the last 30 years.
 
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
 		 	   		  
 1437024410.0


More information about the Toybox mailing list