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

[Casey Schaufler]

On 11/7/2014 8:36 AM, Lennart Poettering wrote:
> On Fri, 07.11.14 15:43, WaLyong Cho (walyong.cho at samsung.com) 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.
>> 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
> So, here you are talking about *files* that have the SMACK64EXEC and
> SMACK64 type labels, while the *process* only as one generic label
> type.
>
> With your patch you want to introduce SmackLabelExec= now. It's a
> label applied to a *process* however, not to a *file*, right?

Yes, it would apply to the process, not the file. We're talking 
about the Smack attribute on the process, not a SMACK64EXEC
attribute on the program file.

>
> This appears incompatible to me: I mean, if a process only has one
> single generic label, and doesn't distuingish between SMACK64 and
> SMACK64EXEC type labels, why would you call the option SmackLabelExec=
> and not the more generic SmackLabel=?

It seemed like a good idea at the time.


>
> This really doesn't make sense to me.
>
> I have no understanding of SMACK, and I am not sure I want to
> understand it, and I figure I'd merge the patch regardless which name
> you pick for the option, but this is a bit too blatantly contradictory
> for me to completely ignore.
>
> Let my simplify my questions:
>
> a) Why would you call a setting that controls a label is written into
>    /proc/$PID/attr/current SmackLabelExec= instead of just
>    SmackLabel=?
>
> b) If SmackLabelExec= is appropriate (which it might well be, after
>    all I really don't grok this), and SmackLabel= is a misnomer that
>    would suggest that something different would happen than actually
>    assumed, then what would an option by the name SmackLabel= for a
>    service unit do differntly from one called SmackLabelExec?
>
> For both SELinux and AppArmor we now have simple options:
> SELinuxContext= and AppArmorProfile=. They only come in one flavour,
> and apply a label/profile to the process being executed and that's
> it. Why would SMACK be more complicated there so that SmackLabel= and
> SmackLabelExec= would even be a distinction?

Calling it SmackLabel= instead of SmackLabelExec= would be fine as
far as I'm concerned. SmackLabel= is more consistent with SELinuxContext=
and AppArmorProfile=, as you point out.

>
> Lennart
>