[lkml]   [2010]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Fix dmesg_restrict build failure with CONFIG_EMBEDDED=y and CONFIG_PRINTK=n
    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

     \ /
      Last update: 2010-11-15 02:23    [W:0.021 / U:6.640 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site