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

[Linus Torvalds]

On Sat, Nov 13, 2010 at 11:51 AM, Joe Perches <joe@xxxxxxxxxxx> wrote:
>
> Maybe something like this?
>
> Make CONFIG_SECURITY_DMESG_RESTRICT depend on CONFIG_SECURITY
> Remove dependency on CONFIG_PRINTK

No, this is wrong:

> +#ifdef CONFIG_SECURITY_DMESG_RESTRICT
> +extern int dmesg_restrict;
> +#endif

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.

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.

                               Linus
--
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/