Messages in this thread | | | Date | Tue, 31 Mar 1998 03:09:42 -0800 (PST) | From | "Dave G." <> | Subject | Re: Security patch for /proc |
| |
> > Hi, > > I'm not sure I agree with this approach -- perhaps root processes should > not be allowed to use the mount() syscall if root_dir != real_root. The > other main source of nastiness is ptrace() -- this needs to be banned in a > similar manner. There are other ways root could escape a chroot() > jail, we need to think about them and eliminate them one by one. > > Chris >
There are plenty of ways of breaking out of a chrooted environment. mknod() is another gotcha that could easily invalidate a chroot'd environment. Most programs that I end up running in a chroot()d environment, also revoke root privileges. That plus a sane chroot()d file system is the best way to keep intruders within the environment.
Root in a chrooted environment could also potentially allow attackers to sniff network traffic, or bind to privileged ports to facilitate attacks on other systems or create fake services. This combined with the fact you can send signals to other processes would allow you to kill inetd and run your own version that calls a telnetd that stores passwords.
With a lot of work, you could probably harden the kernel to the point where it might just be reasonably secure even when an intruder has root in a chroot()'d environment. So now all you have to do is grep all of the kernel sources for every suser() call and check to see if this is something you want root to be able to do within a chroot()d environment.
And that doesnt even include the system calls that dont require you to be root that can affect elements of the operating system that are outside of the chrooted environment.
Dave
--- --- David Goldsmith dhg@dec.net DEC Consulting http://www.dec.net Software Development/Internet Security http://www.dec.net/~dhg
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |