[Toybox] Squinting at LSM support in cp.

[Rob Landley]

On 07/16/2015 12:26 AM, James McMechan wrote:
> For some odd reason the reply got routed to rob at landley.net not the toybox list...

Heh, I replied to that asking you to repost here, and you'd already done
it. :)

>> 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

If somebody wants to send me an implementation (or a link to a man
page). I still don't have a proper smack test environment. (I have a
snapshot of phone software running in an emulator, but no build
environment for it.)

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

Except permissive actions are the ones that _don't_ have race conditions
when copying a hierarchy. (Or at least less obvious ones.)

> 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

Tell me about it. I'm not the one who opened this can of worms. :)

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

Of course.

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

Nothing supports "unlimited size" on finite block devices. :)

Failure to write acl data can be because the disk filled up, so you
always have to be prepared for it. In the case of cp --preserve I dunno
what the right response is. Returning an error code from the top level
process could mean "failed to create a symlink" not "an important file
is missing its security label".

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

The problem with setting to 700 and then labeling, can the label veto a
chmod after the fact? (I dunno _what_ they can do.)

I'm in the process of cutting a release, so all of this gets punted to
next version. (Which should only be in a month or two, I'm trying to get
my aboriginal linux test environment back in sync with the kernel
releases, and each one of those should flush the toybox updates into a
tested release.)

> 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 have yet to see anybody move beyond simple unix permissions in a way
that doesn't collapse into unmanageable complexity, but people assure me
it works for them.

(I like containers because it mostly just tries to make conventional
unix permissions _nest_, which only adds one new concept to the mix and
it's similar to a concept networking already gave us years ago. There
may be implementation problems with containers, but the design goals are
a lot more obvious and easier to agree on.)

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

Many, many times.

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

Containers. They make sense. (The various _implementations_ are a bit
funky, but that was true of unix in the 80's, too...)

>> Rob

 1437059133.0