[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
F: [Re: Need help. Proof of concept 100% security.]
This is my reply to a response to the post i sent to the bugtraq
mailing list. It is forwarded with permission from timo, who sent it
to me directly.
The original post is available at:
----- Forwarded message from ari <email@example.com> -----
Date: Wed, 20 Aug 2003 17:13:19 -0400
From: ari <firstname.lastname@example.org>
To: Timo Sirainen <email@example.com>
Subject: Re: Need help. Proof of concept 100% security.
firstname.lastname@example.org said this stuff:
> On Wed, 2003-08-20 at 20:31, ari wrote:
> > Privilege separation is (1) not always an option, and (2) not a complete
> > solution. For example, one may still open network sockets in a
> > chroot(2) environment, while running as a non-root user.
> Yes, that is annoying. djb just suggested implementing disablenetwork()
> call to prevent it. I'd like that, it's much more important than giving
> rights to other parts of your system which you can mostly already do
> with chroot().
I agree, and i do recall dan bernstein's suggestion. However,
disablenetwork() is a pointed hack, whereas what i'm suggesting is a
more general design.
> > One may still "fork bomb".
> Not necessarily. I use setrlimit() to restrict user's process count to
> one after dropping root privileges. Seems to work with all OSes that
> support RLIMIT_NPROC.
Ah, exactly! That was part of my point, in response to anil's mail, in
that if a programmer is willing to deal with the "complexity" of
implementing resource limits, the programmer should be willing to deal
with the "complexity" of dropping privileges to invoke system calls.
Notice that i discussed resource limits in the sentence directly
> > I created a page about the idea, which can be found at:
> > http://www.episec.com/people/edelkind/patches/kernel/flowpriv/
> "This would be a modification to the chroot call, verifying that the
> user is not attempting to change out of its current root, but allowing
> the user to restrict its root further"
> I hope you understand the problem with hardlinks and setuid binaries?
> Maybe just disallow executing setuid binaries inside chroot.
I think it would be a good idea to disable the execution of setuid
binaries within user-chroot trees. But i don't think i'll actually
include that in this patch anyway, since it doesn't follow the same
logic as the rest. It gives me too much of a congressional-bill-style
> Also please make UNIX socket privileges completely separated from
> network socket privileges.
But of course. Just as filesystem read privileges will be different
from filesystem write, which will be yet different from filesystem
create. In my current plans, unix domain sockets will fall under
Since you sent this directly to me, i'd like to ask permission to
forward this e-mail to the email@example.com mailing list. If you
like, i will be happy to mask or modify your name and/or e-mail address
as you see fit.
----- End forwarded message -----