[systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[WaLyong Cho]

On 10/29/2013 07:48 AM, Kok, Auke-jan H wrote:
> On Mon, Oct 28, 2013 at 1:09 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
>> On Mon, 28.10.13 12:59, Kok, Auke-jan H (auke-jan.h.kok at intel.com) wrote:
>>
>>> On Mon, Oct 28, 2013 at 8:58 AM, Lennart Poettering
>>> <lennart at poettering.net> wrote:
>>>> On Mon, 28.10.13 19:44, WaLyong Cho (walyong.cho at samsung.com) wrote:
>>>>
>>>>> At the same reason of /run and /dev/shm, when systemd is running with
>>>>> SMACK, countless tasks are failed by missed privilege.
>>>>> To avoid, /tmp is assigned '*' label.
>>>> Won't this break if people compile systemd with SMACK enabled but
>>>> run a kernel that has it disabled?
>>>>
>>>> We had a similar problem for the other mounts like /run, where we found
>>>> a somewhat nice solution, but I am not sure how we can make the same
>>>> work here...
>>> Our posts intersected, badly. Yes, as I said in my mail, this sadly
>>> does a bad job for those folks running with smack enabled in systemd
>>> but with it disabled in the kernel.
>>>
>>> For Tizen, we're thinking of just keeping this patch out of tree (and
>>> it will just be a one-liner).
>>>
>>> We could do a ConditionSecurity=Smack, or something like that (ottomh)
>>> but we'd get duplicate tmp mounts, which is bad due to the way we name
>>> mount units. ick.
>> Hmm, here's an idea: there has been a long standig feature request to
>> add a configurable boolean to mount unit files that controls
>> /bin/mount's "-s" switch. Let's say we call it
>> "SloppyOptions=yes/no", or so. Then, we could set this for this unit
>> file and apply the rest of the patch and things should work, and where
>> they don't we can easily reassign to the kernel to respect the "-s" flag
>> properly.
>>
>> Doing a patch that allows "-s" to be controlled should be fairly easy,
>> would be happy to merge a patch for that!
> ahhh I hadn't even seen -s in /bin/mount yet, so I can see this
> helping out a lot.
>
> I'd be okay with a solution like that, it would certainly simplify
> things a lot, but we need to be careful not to overload mount options
> with all sorts of nonstandard options - it will make problems harder
> to debug and for some of these security enabled systems we will most
> likely want to actually _not_ use -s. After all, we want to make sure
> we're actually booting with properly setup Smack options e.g. a typo
> in 'nodev,nosuid,nexec' could be disastrous. (typo deliberate).
>
> Auke
>
I am not sure we can use the -s option. First I tried that in my fedora
machine.

    # mount -t tmpfs -s -o mode=1777,strictatime,smackfsroot=* tmpfs /test
    mount: wrong fs type, bad option, bad superblock on tmpfs,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

    # dmesg
    [  752.222803] tmpfs: Bad mount option smackfsroot


In spite of the -s option, we can still see "Bad mount option
smackfsroot". Was I something wrong?

How about add specific options for smack? According to
http://schaufler-ca.com/description_from_the_linux_source_tree

Smack supports some mount options:

    smackfsdef=label: specifies the label to give files that lack
    the Smack label extended attribute.

    smackfsroot=label: specifies the label to assign the root of the
    file system if it lacks the Smack extended attribute.

    smackfshat=label: specifies a label that must have read access to
    all labels set on the filesystem. Not yet enforced.

    smackfsfloor=label: specifies a label to which all labels set on the
    filesystem must have read access. Not yet enforced.

If we support 'SmackFsRoot=label' option and append the 'smackfsroot'
option after checking the smack by test_security("smack"), then I think
we can solve most problems.(with Auke's worry)

WaLyong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131029/ad882483/attachment-0001.html>