[systemd-devel] [PATCH] SMACK: Add configuration options. (v3)

Kok, Auke-jan H auke-jan.h.kok at intel.com
Mon Oct 29 20:17:32 PDT 2012


On Mon, Oct 29, 2012 at 7:38 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 29.10.12 15:30, Auke Kok (auke-jan.h.kok at intel.com) wrote:
>
>> This adds SMACK label configuration options to socket units.
>
> Merged!
>
> But made a couple of changes on the way: I think the new confi options
> should clarify that you configure the security *label* with them, so I
> renamed them to "SmackLabel=" and similar.

ok, fine with me

> I also merged the three items in the man page into one, so that people
> are hopefully less annoyed about "OMG i am not running my stuff with
> SMACK OMG why is all this stuff in my systemd OMG systemd is bloated
> OMG". After all people only complain about stuff that appears big even
> if it is rather trivial in code.

Did you copy the section of the commit message here that states that this
doesn't add any libraries and just uses fsetxattr()? This may help to deter
those thoughts... ;^)

> One more thing though:
>
> I think it would be cool to have support for SMACK in
> ConditionVirtualizatin= as well. Currently this can be used to hook in
> certain services only if SELinux is used. it would be cool if we'd have
> similar support for SMACK too. (And also for IMA...) Any chance you can
> hack that up for SMACK? is there a nice way to detect whether SMACK is
> in the kernel and enabled?

yes, you can detect it by reading /proc/filesystems and checking for
"smackfs", and
if mounted, that it's enabled.

It's a bit more complicated, but the smack userspace tools install a
service unit
that mounts-and-loads all smack access rules. So, it's fairly safe to
assume that
if smackfs is mounted, that SMACK is enabled and operational.

It's certainly worth to check the Condition - I'll add it to my list.

> BTW, what loads the SMACK policy? We currently load the SELinux and IMA
> policies right from PID 1 itself, before we invoke anything else. My
> guess is that SMACK or AppArmor policies should probably be loaded
> similar early, since they should probably be in effect before the first
> process is forked off..

the smack service has DefaultDependencies=no, so it's fairly adequate.
I'm not sure
whether running it earlier is urgent, but it's certainly something I
am willing to
investigate and implement if this is worth it, so, I'll look into that.

bootchart first though, grrr ;^)

Auke


More information about the systemd-devel mailing list