[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: fedora-startqa




> -----Original Message-----
> From: fedora-devel-list-bounces redhat com [mailto:fedora-devel-list-
> bounces redhat com] On Behalf Of Michael Schwendt
> Sent: Friday, April 02, 2004 1:10 PM
> To: Development discussions related to Fedora Core
> Subject: Re: fedora-startqa
> 
> On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote:
> 
> > What is djinni,
> > and why isn't it included in mach if it makes it secure enough for
> > casual use?
> 
> http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/
> 

Ok so now I know what djinni is. And it does nothing to increase the
security of mach. It says "vserver-djinni is used to do privileged tasks
like directory mounting in unprivileged vservers.". 

It is in fact a workaround to using a vserver kernel, which I did note
as a possible security improvement for someone willing to invest the
time to figure it out.

All that being said, to my knowledge vserver consists of a patched
chroot call, a series of capabilities and resource limitations, process
tree separation, and a bunch of tools to facilitate binding to a single
network alias, etc. Most of this stuff is irrelevant to building as an
unprivileged user.

I'd like someone to please demonstrate how building under a chroot
running under a non-privileged user is a true security risk to a
development machine. Moreso than, for instance, exposing an http or ssh
daemon. An SRPM will do fine. Again, the system is supposed to be secure
against local root exploits from unprivileged users to start off with,
and running in a chroot only provides an added level of security. If the
mach chroot installs weak suid binaries, then that's an os-level
problem, and for that matter one that could be fixed pretty easily in
mach by removing the suid bit on every file it installs.

I don't have a problem pointing out to prospective QA'ers that they may
get rooted, but by that line of reasoning we'd better start including
those disclaimers with every copy of bind, sshd, or apache that get
shipped with the OS too. There is an element of risk in everything, and
smart security is all about risk management, not paranoia.

If you're really concerned, there will never be a better option than a
dedicated machine without network access, but how usable is that? We're
trying to REDUCE barriers to entry, aren't we?

--erik






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]