Re: [PATCH PLACEHOLDER 1/3] fs/exec: "always_unprivileged" patch

[Casey Schaufler]

On 1/15/2012 12:59 PM, Andrew Lutomirski wrote:
> On Sun, Jan 15, 2012 at 12:16 PM, Casey Schaufler
> <casey@xxxxxxxxxxxxxxxx>  wrote:
> > On 1/14/2012 12:22 PM, Linus Torvalds wrote:
> > > And yes, I really seriously do believe that is both safer and simpler
> > > than some model that says "you can drop stuff", and then you have to
> > > start making up rules for what "dropping" means.
> > >
> > > Does "dropping" mean allowing setuid(geteuid()) for example? That *is*
> > > dropping the uid in a _POSIX_SAVED_IDS environment. And I'm saying
> > > that no, we should not even allow that. It's simply all too "subtle".
> >
> > I am casting my two cents worth behind Linus. Dropping
> > privilege can be every bit as dangerous as granting privilege
> > in the real world of atrocious user land code. Especially in
> > the case of security policy enforcing user land code.
> Can you think of *any* plausible attack that is possible with my patch
> (i.e. no_new_privs allows setuid, setresuid, and capset) that would be
> prevented or even mitigated if I blocked those syscalls?  I can't.
> (The sendmail-style attack is impossible with no_new_privs.)

I am notoriously bad at coming up with this sort of example.
I will try, I may not hit the mark, but it should be close.

The application is running with saved uid != euid when
no-new-privs is set. It execs a new binary, which keeps
the saved and effective uids. The program calls setreuid,
which succeeds. It opens the saved userid's files.

Some people reading this will say this is expected and
appropriate behavior, and others will say it's an exploit
under sandbox conditions. Those in the latter group can
point out that blocking setreuid() would prevent what
they consider an exploit. Those in the former group will
say blocking the setreuid would introduce a denial of
service that could lead to an exploit if the program is
poorly written.

Because the correctness of the behavior is ambiguous
(to me at least) when no_new_privs is set I argue that
we shouldn't have it. If we are going to have it my
feeling is that it should be as draconian as possible.
Because you can't always tell if state A is "more"
privileged than state B, any change between A and B has
to be treated as an escalation.

> Also, how would you even block setuid(2) in a non-confusing manner?
> The semantics and error returns are already such a disaster than it's
> barely worth it for anything to check the return value.
>
> > This even more important in environments that support fine
> > granularity of privilege, including capabilities and SELinux.
> > Under SELinux a domain transition can increase, decrease or
> > completely change a process' access rights and there is really
> > no way for the kernel to tell which it is because that's all
> > encoded in the arbitrary SELinux policy. Smack does not try
> > to maintain a notion of hierarchy of privilege, so the notion
> > of any change being equivalent to any other is in line with
> > the Smack philosophy.
> My patch does not (barring bugs) allow selinux domain transitions.  I
> certainly think that all security transitions that vary across
> distributions should be blocked by no_new_privs.
>
> --Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/