On 11/7/2014 8:36 AM, Lennart Poettering wrote: > On Fri, 07.11.14 15:43, WaLyong Cho (walyong....@samsung.com) wrote: > >> On 11/07/2014 09:35 AM, Lennart Poettering wrote: >>> On Fri, 07.11.14 04:17, WaLyong Cho (walyong....@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 > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
