Ok, thanks a lot for your patience with this ! > The kinds of attacks you're talking about--bad emails, trojan web pages, etc. may seem like remote attacks, but from an OS standpoint, they're really not: they originate someplace else, but they trick users into doing something locally, and they need to be treated as such.
I don't understand -- could you elaborate on "they need to be treated as such" ? I wrote earlier : > Why bother chrooting apache, for example, and not leaving it with your > recommended systrace? What's the answer to this one? I was also toying around with this setup: * One jail for the XServer * One jail for the "desktop clients" with the required libraries for these and not more (no sh, no gcc), * and ssh-xterm-login connect to outside the jail, where all system files are available In particular, one directory /jails/xserver/ from the xserver runs, a directory /jails/xclients/ which has for example the whole gnome system. It also has a subdirectory /jails/xclients/home/ so that the home directories are visible from the "desktop". Does that solve your "and if it goes, you will have lost the system for all practical purposes just as effectively as if the jail weren't in place." ? Stephan On 5/26/05, Jay Savage <[EMAIL PROTECTED]> wrote: > On 5/26/05, Stephan Wehner <[EMAIL PROTECTED]> wrote: > > Thanks a lot for your reply. -- Are you saying there is too much > > overhead or the end result is not worth any overhead?? > > > > Why bother chrooting apache, for example, and not leaving it with your > > recommended systrace? > > > > My question is motivated by exploits through Internet access; it seems > > to me server vulnerabilities are comparable to user's visiting unsafe > > websites / opening unsafe emails, etc. Plus, more and more user > > activity involves Internet access. > > I can speak for Mike, but I'd say "both". In order to give your users > a useable system, you'd have to compy almost everything into the jail, > which would mean maintaining two version of everything. And at the end > of the day, what have you gained? > > Look at it this way: assuming you have any reasonable hardware > policy, any system that a user logs on to with a graphical interface > exists primarily to run user applications--Joe L'User shouldn't be > running a KDE session on any of your file, internet, mail, database, > etc. servers. So anything that would make a workstation/X server > usable would need to be chrooted. If it wouldn't need to be chrooted > so the users have access, why have it on that machine at all? Once > you realize that, you realize that, given the purpose of workstations > and X servers, if anything happens inside the jail, it's just as bad > as if it had happened outside the jail: you'll just as big a mess on > your hands, because *everything important*--executables, spool files, > password files, log files, all of it--will have to be in the jail. and > if it goes, you will have lost the system for all practical purposes > just as effectively as if the jail weren't in place. > > chrooting is a technique to protect leaky programs from remote > attacks; OpenBSD provides other tools--file permissions, file system > flags, etc.--to protect against locl exploits. Use the appropriate > tools for the job. > > The kinds of attacks you're talking about--bad emails, trojan web > pages, etc. may seem like remote attacks, but from an OS standpoint, > they're really not: they originate someplace else, but they trick > users into doing something locally, and they need to be treated as > such. > > -- jay > -------------------- > daggerquill [at] gmail [dot] com > http://www.engatiki.org
