[Toybox] Squinting at LSM support in cp.

[enh]

On Tue, Jul 14, 2015 at 5:31 PM, Rob Landley <rob at landley.net> wrote:
> 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.)
>>
>> 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?)

actual security guy says:

No, that's not true.

1) SELinux is a whitelist, and if a particular operation isn't defined
in policy, then the operation isn't allowed.

2) SELinux works in conjunction with standard Unix permissions. Only
if SELinux says "yes" AND standard UNIX permissions say "yes" is an
operation allowed. An SELinux rule by itself cannot grant capabilities
that would be disallowed by the standard UNIX permission system.

A label is always assigned to a file by the kernel. By default, a new
file's label is inherited from the label of the enclosing directory,
unless setfscreatecon() is used or a dynamic type transition is
defined in policy, both fairly rare occurrences. For example, doing a
plain copy of a file to /data/dalvik-cache results in the file having
the dalvik-cache label.

root at shamu:/ # ls -laZ /sepolicy
-rw-r--r-- root     root              u:object_r:rootfs:s0 sepolicy
root at shamu:/ # cp /sepolicy /data/dalvik-cache
root at shamu:/ # ls -laZ /data/dalvik-cache/sepolicy
-rw-r--r-- root     root
u:object_r:dalvikcache_data_file:s0 sepolicy

Moving the file preserves the label on the file.

> That would make the race conditions a lot less of an issue, yes.
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1437068502.0