[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
    Why not implement this as another securebit? So far as I can see the
    whole thing can be implemented in the capability LSM.

    What is less clear to me is whether per-process 'disabling of setuid
    bits on files' should force mandatory disabling of file capabilities.
    It seems as if disabling the transition of one luser to another luser
    through a setuid executable is something distinct from privilege

    Since there is already independent support for disabling file
    capabilities (the privilege escalation part), I see these two
    mechanisms as separable.



    On Thu, Dec 31, 2009 at 9:52 AM, Serge E. Hallyn <> wrote:
    > Quoting Alan Cox (
    >> > I see this as being a security-model agnostic API - the reason being,
    >> Thats what everyone else says about their security model too
    > LOL
    >> > 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.
    > That's exactly what we're trying to avoid :)  But I'm personally not
    > against making this an LSM.  As you say:
    >> 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
    >> place.
    >> Yes it might mean the hooks need tweaking, yes it probably means the
    > Yes, and in particular, we'll need to do something about data
    > ->security annotations, since, if we make this an LSM, then we can't
    > use a per-thread flag.
    > This feature is used during exec and ptrace, not on hot-paths, so
    > dereferencing task->security would be fine.  But finding a way to
    > multiplex task->security so it can be used by Eric's nosuid lsm,
    > Michael's disablenetwork LSM, and SELinux/smack/apparmor, that
    > will likely take months, and, history shows, may never happen.
    >> 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.
    > Eric, the thing is, once an API goes upstream, we can't change it,
    > but in contrast we can change how task->security is used at any time.
    > So I'd suggest just adding
    >        short nosuid;
    > #endif
    > or something like it next to the
    > #ifdef CONFIG_SECURITY
    >        void *security;
    > #endif
    > in struct cred and doing that for a first go.  You could
    > share that field with Michael's disablenetwork, or not if you
    > prefer - either way, it keeps you and SELinux out of each other's
    > ways.
    > -serge
    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 19:23    [W:0.028 / U:14.684 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site