[systemd-devel] [PATCH] condition, man: Add support for ConditionSecurity=smack

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 08, 2013 at 11:42:34AM -0700, Kok, Auke-jan H wrote:
> On Tue, May 7, 2013 at 5:29 AM, Karol Lewandowski
> <k.lewandowsk at samsung.com> wrote:
> > On 05/07/2013 01:32 PM, Lennart Poettering wrote:
> >> On Tue, 07.05.13 13:21, Karol Lewandowski (k.lewandowsk at samsung.com) wrote:
> >>
> >> Heya,
> >>
> >> Hmm, does that directory always exist? Or only if AppArmor is actually
> >> runtime enabled?
> >
> > /sys/fs/smackfs is only registered when smack lsm is actually enabled:
> >
> >   https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smackfs.c?id=e93072374112db9dc86635934ee761249be28370#n2179
> >
> >> I.e. this check should ideally only return true if SMACK is not only
> >> built into the kernel, but actually really enabled during
> >> runtime. That's what the SELinux check does and what the most useful
> >> semantics are.
> >
> > Ok, I see that libselinux will consider selinux to be disabled also when
> > policy is not loaded:
> >
> >   http://userspace.selinuxproject.org/trac/browser/libselinux/src/enabled.c#L12
> >
> > I guess we could do something similar (inspect /proc/self/attr/current)
> > but honestly, I don't think it's really needed.  Rafał, could you correct me
> > if I'm wrong?
> 
> smack is different as in that it can function without any loaded
> policies, so looking at policies isn't the right thing for smack. So
> likely looking at the presence of smackfs is exactly the same as
> looking at the preference of /proc/self/attr/current, except the
> latter is more complex, so less desirable imho.
Applied, with a commit message based on this explanation.

Zbyszek