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

[Lennart Poettering]

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?

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=?

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?

Lennart

-- 
Lennart Poettering, Red Hat