Re: [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=yand CONFIG_PRINTK=n

[James Morris]

On Sat, 13 Nov 2010, Linus Torvalds wrote:

[Adding the LSM list]

> CONFIG_SECURITY_DMESG_RESTRICT is supposed to be about the initial
> _value_ of dmesg_restrict, not about whether it exists or not. If you
> don't have CONFIG_SECURITY, you still end up defaulting to the common
> capability model, and it would still want that dmesg_restrict thing.
> 
> But what can make sense is to move "dmesg_restrict" into
> security/commoncap.c, and just make it about capabilities. Of course,
> that then means that if you use some other security model that just
> doesn't care about capabilities at all, they'll never care about
> dmesg_restrict either. So that, to me, smells of really bad interface
> design.

Yes, it should not be possible for an LSM to reduce the default security 
-- an interface which allows this breaks the security model.

> We had this exact problem with the whole "mmap_min_addr" thing. People
> _thought_ of it as generic, but because it was actually tested by the
> security logic, if you ended up enabling SELinux the test actually
> went away entirely (or maybe it was the other way around). So with
> certain security models, the whole thing was bypassed, and the
> security module actually became an _IN_security module.
>
> That's why I don't think we should do things like this inside the
> security models themselves. People just get really confused about what
> the real semantics are.
> 
> If something should be generic (and by all accounts, that's the
> intention of 'dmesg_restrict', the same way it was for
> 'mmap_min_addr'). Which is why I'd change the whole idiotic
> security_syslog() model itself as per the patch I just sent out.

Looks like the right approach to me.

Kees, does this patch work for you?

I want to ensure that LSMs which implement security_syslog can't end up 
with a less secure system than the default, regardless of whether they 
call cap_syslog or not.


- James
-- 
James Morris
<jmorris@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/