[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: thoughts on kernel security issues

    On Thu, 13 Jan 2005, Christoph Hellwig wrote:
    > On Wed, Jan 12, 2005 at 08:48:57PM -0800, Linus Torvalds wrote:
    > > Without that capability set, you can only execute binaries that you cannot
    > > write to, and that you cannot _get_ write permission to (ie you can't be
    > > the owner of them either - possibly only binaries where the owner is
    > > root).
    > I think this is called "mount user-writeable filesystems with -noexec" ;-)

    You miss the point.

    It wouldn't be a global flag. It's a per-process flag. For example, many
    people _do_ need to execute binaries in their home directory. I do it all
    the time. I know what a compiler is.

    Others do not necessarily do that. Sure, you could mount each users home
    directory separately with a bind mount, but that's not only inconvenient,
    it also misses the point - it's not about _where_ the binary is, it's
    about _who_ runs it.

    What is the real issue with MS security? Is it that NT is findamentally a
    weak kernel? Hey, maybe. Or maybe not. More likely it's the mindset that
    you trust everything, regardless of where they are. Most users are admins,
    and you run any code you see (or don't see) by default, whether it's in an
    email attachement or whatever.

    Containment is what real security is about. Everybody knows bugs happen,
    and that people do stupid things. Developers, users, whatever. We all do.

    For example, in many environments it could possibly be a good idea to make
    even _root_ have the "can run non-root binaries flag" clear by default.
    Imagine a system that booted up that way, and used PAM to enable non-root
    binaries on a per-user basis (for developers who need it or otherwise
    people who are trusted to have their own binaries). Think about what that

    Every single deamon in the system would have the flag clear by default.
    You take over the web-server, and the most you have to play with are the
    binaries that are already installed on the system (and the code you can
    inject directly into the web server process from outside - that's likely
    to be the _real_ security hazard).

    It's just another easy containment. It's not real security in itself, but
    _no_ single thing is "real security". You just add containment, to the
    point where it gets increasingly difficult to get to some state where you
    can do lots of damage (in a perfect world, exponentially more so, but
    these containments are seldom independent or each other).

    NOTE! I'd personally hate some of the security things. For example, I
    think the "randomize code addresses" is absolutely horrible, just because
    of the startup overhead it implies (specifically no pre-linking). I also
    immensely dislike exec-shield because of the segment games it plays - I
    think it makes sense in the short run but not in the long run, so I much
    prefer that one as a "vendor feature", not as a "core feature".

    So when I talk about security, I have this double-standard where I end up
    convinced that many features are things that _I_ should not do, but
    others likely should ;)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.024 / U:125.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site