Re: Bug in how capability inheritance is handled in "fs/exec.c", 2.3.99

From: Theodore Y. Ts'o (tytso@MIT.EDU)
Date: Mon May 29 2000 - 18:26:04 EST


   Date: Mon, 29 May 2000 20:08:50 +0200
   From: Pavel Machek <pavel@suse.cz>

> That is, the whole concept of a "root shell" is prohibited by the POSIX
> 1.e Draft 17 rules. In fact the shell's executable runs with (P,I,E) =
> (0,0,0), so by default you don't run with any privileges whatever.
> Instead, the backup program would have CAP_DAC_READ_SEARCH (and thus be
> considered part of the TCB), and could enforce its own access control
> policies about who was allowed to execute the program.

   Oh... Nearly every utility enforcing its own access control? That
   means that buffer overrun in almost every utility means security
   problem! Remembering what harm setuid programs already did, that does
   not smell good.

I think I actually overstated things when I said that "root shell" is
prohibited. It doesn't have to run with PIE=(0,0,0). Linda was right
on that score. (That is one way of doing things, but it's not the only
way of doing things.)

Still, even given that you're running with a shell with privileges,
given that most executables have a PIE of (0,0,0), it means that they
won't inherit any privileges by default. So "rm" would only get
privileges if it was explicitly allowed to inherit DAC override (for
example --- no reason to allow it to inherit CAP_SETUID, or CAP_SETPCAP,
or any other privilege).

                                                - Ted

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



This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:22 EST