[lkml]   [2010]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH v3] Unprivileged: Disable raising of privileges
    > Sure. Not that it would be hard to do so. And have a careful look
    > at the recent discussions on checkpoint/restart.

    Indeed the LSM "no removal of restrictions" is simply a policy decision
    that came about early on - no reason to assume it is a right policy
    decision if it can be shown otherwise.

    > Application developers want systems that work the way the man pages
    > say they work. They do not want additional or conditional restrictions.

    I disagree somewhat. They want them to work they way they did when they
    tested it and the way they believe it works. Most of them never read the
    manual or the standards documents. Take a look at the whining when stat()
    size data stopped happening by chance to reflect bytes queued in a pipe.

    > How many commercial applications start their installation instructions
    > with "disable SELinux"? (Hint: lots)

    And I am sure it time the sequence is going to go "Why did your business
    web site get taken out for four weeks" / "We disabled SELinux as the app
    said" / "Sue the app vendor"

    If you tell someone to disable the safety systems on a crane you get

    > > I am sick and fed up with the conversations that go:
    > > - I want to do X.
    > > - X has been implemented.
    > > - Sorry I can't use X as implemented because you have to be root to
    > > use X.
    > >
    > Exasperated sigh. Privileged operations are privileged for a reason,
    > not always a good reason mind you, but a reason nonetheless. If
    > your application developers want to do things that require privilege
    > you need to teach them how to write privileged programs safely. We've
    > been working on exotic variations of system controls for decades
    > and in the end your programmers have to write decent code because
    > we haven't yet come up with a way to make all the things that people
    > want their programs to do safe.

    A useful question here would be to ask what it means to containerise
    security. At the moment you can do this with virtual machines and while
    its a nasty managability/security trade off the choice is there for the
    most part and you can point at things like the amazon cloud as working
    examples. We don't really have the notion of what setuidness means within
    a container or how you can create a container which has its own internal
    setuid, security model, LSM and 'superuser' but can't mess anything else
    up, only for a virtual machine.

    [I'll note Hurd tried to explore this area in part because Hurd was
    designed around a model that history proved bogus - a big computer being
    equitably shared with all the power possible but without messing up other


     \ /
      Last update: 2010-01-01 23:41    [W:0.022 / U:49.112 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site