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

[WaLyong Cho]

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


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.


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
>