[RFC][PATCH][CVS] chroot jailing support

[Henrique de Moraes Holschuh]

On Sun, 29 Dec 2002, Lawrence Greenfield wrote:
> --On Monday, December 30, 2002 12:52 AM -0200 Henrique de Moraes Holschuh 
> <hmh at debian.org> wrote:
> >The codepaths in master are MUCH easier to audit, so I think it overall
> >enhances the security of Cyrus to run services inside chroot jails. IF it
> >is done right.
> >
> >Any comments?  Should I submit this to CMU for inclusion on Cyrus
> >eventually (if they like it)?
> 
> What's your goal? What's the threat model? For instance, do you want to:
> Prevent someone who has a Cyrus exploit from using a local root exploit?

Exactly.

>  -> why not chroot master before dropping privs and just stay that way the 
> entire time? We can exec each service starting up and fork the services, 
> not master. This is more complicated (which is why it isn't implemented) 
> but has some nice performance properties: it should use less memory than 
> the current fork/exec strategy, and it allows mixed thread/process models 
> more easily.

Chrooting master itself is already there :)  You just enter a chroot jail
first, then run master.  So, it doesn't need any sort of code changes, and
people who like the idea probably are already doing it...

>  -> is it interesting? After breaking Cyrus the attacker probably has 
> everything of value on the system anyway.

True. However, he cannot install trojans in the kernel, nor launch stealth
probes that require root access, so the damage to other stations in the
network is lessened.   And the local intrusion monitors are much harder to
avoid if you are not root...

What I *really* would like to do is to have chroot jails per user. But THAT
is not feasible without a huge amount of work.

> Prevent the compromise of a single Cyrus service from compromising other 
> Cyrus servers?

That too, in a murder cluster.

>  -> I'm not sure this is an interesting exercise. The services most 
> vulnerable to exploitation need to have read/write access to the entire 
> mail spool.

Yes. We cannot easily protect the mail spool without a lot of huge changes
to Cyrus.  I think we would need to at least:

1.  Switch to forking/multithreaded services model (so that we can load
    all dynamic libraries first)
2.  Use IPC/pipes/whatever to talk to master (or another long-running
    daemon), and let it keep all global state (mailbox db, tls and duplicate
    dbs...)

I do think it might be worth the effort to do that, but it is beyond my
alloted time to Cyrus (and I think, I would rather someone far more
proficient in C than I am did it, instead).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh