[systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[Casey Schaufler]

On 11/6/2014 10:43 PM, WaLyong Cho wrote:
> On 11/07/2014 09:35 AM, Lennart Poettering wrote:
>> On Fri, 07.11.14 04:17, WaLyong Cho (walyong.cho at gmail.com) wrote:
>>
>>> SMACK64
>>> 	Used to make access control decisions. In almost all cases
>>> 	the label given to a new filesystem object will be the label
>>> 	of the process that created it.
>>> SMACK64EXEC
>>> 	The Smack label of a process that execs a program file with
>>> 	this attribute set will run with this attribute's value.
>> I am sorry, but I cannot parse this.
>>
>> "The smack label .... will run with this attribute's value"? smack
>> labels "run"? That sentence makes no sense to me at all...
>>
>> Again, what kind of objects are SMACK64 and SMACK64EXEC applied to?
>> files? processes?
> Sorry, I'm also confused.
> OK, I asked some about this to my security friend.
> And I add Casey Schaufler who the Author of smack.
> I hope my below explain it not wrong. But if not, please point out.
>
>
> Quoting the Wikipedia:
>> In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices etc.
>
> In case of SMACK, subject is SMACK64EXEC and object is SMACK64.

The SMACK64 attribute of any object (file, directory, IPC object, ...)
is used in access control decisions on that object.

The SMACK64EXEC attribute is very much like the setuid bit on an executable.
If the attribute is set (and it should almost *never* be set) on a program file
the process execing the program will change its Smack label to the value in
the SMACK64EXEC attribute.

On execution:

The existing process Smack label must allow eXec access to the program file,
based on the Smack label of the process and the SMACK64 attribute of the
program file. If there is no SMACK64EXEC attribute on the file the Smack label
of the process is unchanged. If there is a SMACK64EXEC attribute the Smack label
of the process changes to that value.

Note that the SMACK64 attribute is present on all files and has no impact on
the Smack label of the process. The SMACK63EXEC attribute is optional. Most
program files do not have this attribute. It should be only used in cases where
the Smack label of the program must always be a particular value.

Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you
want a system bus and a user bus with different attributes you want it to get
the Smack label at launch time, just like you do for UID and capability sets.

> Assume like this: /usr/bin/dbus-daemon has both label. SMACK64 is "foo"
> and SMACK64EXEC is "bar". And current process (what will execute the
> /usr/bin/dbus-daemon) has "foo" label. Let's assume the current process
> is sh. Then /proc/$$/attr/current of sh is "foo". There is no problems
> to sh execute the /usr/bin/dbus-daemon because the sh has same label
> with /usr/bin/dbus-daemon. Now /usr/bin/dbus-daemon will be executed by
> sh. But it has SMACK64EXEC label "bar". So executed attr/current of
> /usr/bin/dbus-daemon is "bar".
> If the sh has label "waldo", then maybe two case can be existed. If
> label "waldo" has executable rule for label "foo" then the sh can
> execute the /usr/bin/dbus-daemon. But if label "waldo" has no rule for
> that, then sh can not execute the /usr/bin/dbus-daemon. EACCESS will be
> occurred. If label "waldo" has executable rule for label "foo" and
> /usr/bin/dbus-daemon was executed. Then the executed dbus-daemon process
> has attribute "bar" at /proc/{pid of dbus-daemon}/attr/current.
>
> # attr -l /bin/sleep
> Attribute "SMACK64" has a 4 byte value for /bin/sleep
> Attribute "SMACK64EXEC" has a 3 byte value for /bin/sleep
> # attr -S -g "SMACK64" /bin/sleep
> Attribute "SMACK64" had a 4 byte value for /bin/sleep:
> foo
> # attr -S -g "SMACK64EXEC" /bin/sleep
> Attribute "SMACK64EXEC" had a 3 byte value for /bin/sleep:
> bar
> # cat /proc/$$/attr/current
> waldo
> # /bin/sleep 100 &
> [1] 15263
> sh-3.2# cat /proc/15263/attr/current
> bar
>
> Additionally, SMACK64EXEC can be none. Then the executed process inherit
> attribute from the caller process. So sh has attribute "waldo" and
> /bin/sleep has only SMACK64 "foo" then the executed /bin/sleep process
> has "waldo" attribute.
>
> # cat /proc/$$/attr/current
> waldo
> # attr -l /bin/sleep
> Attribute "SMACK64" has a 4 byte value for /bin/sleep
> # attr -S -g "SMACK64" /bin/sleep
> Attribute "SMACK64" had a 4 byte value for /bin/sleep:
> foo
> # /bin/sleep 100 &
> [1] 4509
> # cat /proc/4509/attr/current
> waldo
>
>
> Back to the systemd execute problem with User= option. Exclude Netlabel,
> the access checking is ignored for all root uid processes. So there is
> no problems to execute the ExecStart= without User= option.
> But if a service has User= option and executable binary on ExecStart=
> has label "foo" then the fork()-ed systemd child process has no root
> uid. And the child systemd process has "_" label.(see below predefined
> labels.) If "_" has no executable rule for "foo" then access deny will
> be occurred. So to successfully execute the ExecStart=, the child
> systemd process have to has attribute something what can has executable
> rule for the label of ExecStart= file.
> Regarding to new option's naming, we will set attribute of process(child
> systemd). So that is subject. So I think SmackLabelExec= or SMACK64EXEC=
> are more appropriate.
>
> I think we can consider another method. If we don't want to add new
> SMACK option then we can do like this. Read the access label of
> executable file of ExecStart=. And just set the label to attribute of
> fork()-ed child systemd process. Then we don't need to add new SMACK
> option. I'm not sure this is right way.

As mentioned above, it's really valuable to have systemd set the Smack
label from configuration.

>
>
> Regarding to the predefined labels:
> https://www.kernel.org/doc/Documentation/security/Smack.txt
>
> There are some predefined labels:
>
> 	_ 	Pronounced "floor", a single underscore character.
> 	^ 	Pronounced "hat", a single circumflex character.
> 	* 	Pronounced "star", a single asterisk character.
> 	? 	Pronounced "huh", a single question mark character.
> 	@ 	Pronounced "web", a single at sign character.
>
> Every task on a Smack system is assigned a label. System tasks, such as
> init(8) and systems daemons, are run with the floor ("_") label. User tasks
> are assigned labels according to the specification found in the
> /etc/smack/user configuration file.

On Tizen system services run with the label "System" and user environment
services (e.g. X11, weston) run with the label "User". Since these are launched
by systemd it makes sense to include the Smack attribute in the systemd configuration,
just as other security attributes are.

>
>
> Thanks for reading,
> WaLyong
>
>>> (I think I'd confused. We should use SMACK64 or SmackLabel instead
>>> SMACK64EXEC or SmackLabelExec in here.)
>>>
>>> Auke, what do you think?
>> Now I am even more confused than I was before...
>>
>> Lennart
>>