[lkml]   [2009]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH v3] Unprivileged: Disable raising of privileges
    > I see this as being a security-model agnostic API - the reason being,

    Thats what everyone else says about their security model too

    > the application is specifying a policy for itself that has meaning in
    > all existing security models, and which does not require administrator
    > intervention to configure. Rather than reimplementing this for each
    > security model, it's far better to do it just once. Moreover, by
    > having a single, common API, the application can state the general
    > policy "I will never need to gain priviliges over exec" without
    > needing to know what LSM is in use.

    So it can sit in the security hooks and stack.

    > The future goal of this API is to allow us to relax restrictions on
    > creating new namespaces, chrooting, and otherwise altering the task's
    > environment in ways that may confuse privileged applications. Since

    All of which are security policy, general purpose and frequently part of
    the main LSM module loaded - in other words it's nothing of the sort when
    it comes to being separate. Its just another magic interface hook, and as
    I think the history of capability stuff in kernel shows it doesn't work
    that way.

    > security hooks are all about making the existing security restrictions
    > _stricter_, it's not easy to later relax these using the security hook
    > model. And once we put in the general requirement that "this task
    > shall never gain privilege", it should be safe to relax these
    > restrictions for _all_ security models.

    In which case the hooks can be tweaked. It's an interface it can be
    tuned - and has been - eg for Tomoyo.

    > In short, this is something which is meaningful for all existing LSMs

    But is it - and if its combined with 500 other similar hooks and a set of
    system policies can you even work out the result ?

    > restrictions later, it doesn't make sense to put it in a LSM as they
    > stand now.

    And it certainly doesn't make sense to add this and the several hundred
    other variants of this "can't open sockets, can't mount, can't this,
    can't that ...." stuff continually being suggested by randomly extending
    other unrelated interfaces.

    Look up the sendmail security archive and you'll even find examples where
    enforcing extra security on setuid *caused* security problems to show up
    that were basically impossible to hit otherwise.

    We have a security system, with a set of interfaces for attaching
    security models, please stop trying to go round the back of the kernel
    design because you can't be bothered to do the required work to do the
    job right and would rather add more unmaintainable crap all over the

    Yes it might mean the hooks need tweaking, yes it probably means the
    people who want these need to do some trivial stacking work, but if as
    many people are actually really interested as are having random 'lets add
    a button to disable reading serial ports on wednesday' ideas there should
    be no shortage of people to do the job right.


     \ /
      Last update: 2009-12-31 18:35    [W:0.025 / U:11.496 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site