On Fri, Sep 08, 2006 at 12:52:39PM +0200, Pavel Machek wrote:
> Well, you claim it is as safe as possible, and it is not quite.
I claim "safe enough". :-)
> I can bet someone will get the fork() case wrong:
>
> f = fork();
> kill(f);
>
> fork will return -1, and kill will kill _all_ the processes.
Someone who writes code like that deserves to get all his processes
killed. :-p fork() can fail for a million reasons, some of which, on
most systems, can be provoked by a malicious attacker (such as filling
all available process slots).
> If you can find another uid to hijack, that other uid has bad
> problems. And I do not think you'll commonly find another uid to
> hijack.
How about another gid, then? Should we reset all caps on sgid exec?
Ultimately a compromise is to be reached between security and
flexibility... The problem is, I don't know who should make the
decision.
> And there are easier ways to get out of jail with your proposed
> capabilities: you do not restrict ptrace, so you can just ptrace any
> other process with same uid, and hijack it.
That's true. The restrictions on process killing (which Serge
introduced) should probably be applied to ptrace() also.
> (You probably want to introduce CAP_REG_PTRACE).
Good idea. I did, in version 0.4.2.
> Or just remove CAP_REG_XUID_EXEC when removing any other CAP_REG...?
Doable, but ugly (or so I think): there are many paths that set
caps... A simpler solution would be to remove the test on
CAP_REG_SXID and instead test on all regular caps simultaneously.
Still, I really don't like the idea.
> It is not too bad; you'll usually not want restricted programs to exec
> anything setuid... (Do you have example where
> restricted-but-should-be-able-to-setuid-exec makes sense?)
Well, I could imagine that a paranoid sysadmin might want some users'
processes to run without this or that capability (perhaps
CAP_REG_PTRACE or some other yet-to-be-defined capability). This
doesn't mean that they shouldn't be able to run a game which runs sgid
in order to write the score file.
--
David A. Madore
([email protected],
http://www.madore.org/~david/ )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
