[lkml]   [2009]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH v3] Unprivileged: Disable raising of privileges
    On Wed, Dec 30, 2009 at 6:00 PM, Alan Cox <> wrote:
    > On Wed, 30 Dec 2009 13:36:57 -0800
    > (Eric W. Biederman) wrote:
    >> Alan Cox <> writes:
    >> >> Added bprm->nosuid to make remove the need to add
    >> >> duplicate error prone checks.  This ensures that
    >> >> the disabling of suid executables is exactly the
    >> >> same as MNT_NOSUID.
    >> >
    >> > Another fine example of why we have security hooks so that we don't get a
    >> > kernel full of other "random security idea of the day" hacks.
    >> Well it comes from plan 9.  Except there they just simply did not
    >> implement suid.  What causes you to think dropping the ability
    >> to execute suid executables is a random security idea of the day?
    > Well to be fair its random regurgitated security idea of every year or
    > two.
    > More to the point - we have security_* hooks so this kind of continuous
    > security proposal turdstream can stay out of the main part of the kernel.
    > Cleaning up the mechanism by which NOSUID is handled in kernel seems a
    > good idea. Adding wacky new prctls and gunk for it doesn't, and belongs
    > in whatever security model you are using via the security hooks.

    I see this as being a security-model agnostic API - the reason being,
    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.

    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
    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 short, this is something which is meaningful for all existing LSMs
    and should be implemented in a central point, it will make things
    easier for the namespace folks, and since it will lead to relaxing
    restrictions later, it doesn't make sense to put it in a LSM as they
    stand now.
    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-12-31 03:47    [W:0.025 / U:0.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site