[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: breaking chroot with ptrace and shared memory-- is it really possible?
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: breaking chroot with ptrace and shared memory-- is it really possible?
- From: James Strandboge <jstrand1_(_at_)_rochester_(_dot_)_rr_(_dot_)_com>
- Date: 18 Jul 2003 11:43:47 -0400
- Cc: chuck+obsd_(_at_)_2003_(_dot_)_snew_(_dot_)_com
On Fri, 2003-07-18 at 01:26, Chuck Yerkes wrote:
> Chroot is handy to keep generally non-malicious bugs from
> affecting things around the system. No good security person
> will claim that chroot is real protection.
> This horse was beaten pretty dead on a couple firewalls lists
> in 1995 or so.
> Oh, and when I *do* run a service as a user, it's not "nobody".
> People kept doing that in a large NFS environment, and I kept
> showing that by coming is as root (or indeed many other users),
> I could be "nobody" on their system and that "nobody" was way
> too priveledged.
> named runs as, er, "named".
> ssh runs as "name^H^H^H^Hssh".
> See, not much runs as "nobody". And less and less runs
> as root.
Ok. As I understand it, the (basic) security philosophy of openbsd is
(not necessarily in this order):
1. run as few things as root as possible
2. chroot what you can to add a layer of security
3. have solid, audited code to minimize bugs that allow compromise via
shared memory, ptrace or anything else
4. run daemons under different uids (another layer of security)
5. have a secure default installation (another layer)
6. use propolice to further prevent exploits in buggy code (another
The gsecurity guy mentioned taking over network services on openbsd is
trivial. However this assumes there is a bug to be exploited and the
exploitation of that bug will allow these calls to ptrace, shmget or
In my estimation, the audited code helps with the bugs and propolice
makes it significantly harder to exploit bugs that are found. Is this a
fair (or naive) assessment?