Re: chroot useful?

[mcnabb () argus-systems com (Paul McNabb)]

>  From: Darren Reed <darrenr () cyber com au>
>  
>  No.  If it can write to /dev/kmem (especially), then all it needs to do
>  is call the mknod(2) system call, create the right device for /dev/kmem,
>  open it, search for the right place in memory to change and voila! No
>  more chroot'd environment.  Most of the buffer exploits for programs
>  could be converted to do that or make it possible.
>  
>  chroot is best used, in the way you describe above, to limit the reach of
>  non-root programs.
>  
>  I wouldn't regard denying write perms to /dev/kmem a panacea either.  I
>  think you need to go a lot further than that before the chroot environment
>  is safe for root programs.  As Steve said, chroot doesn't create a virtual
>  environment which is what you (and a lot of people) confuse it for doing.

Assuming that a root process can't use chroot(2), mknod(2), or chmod(2)
and can't access or reference any files/devices underneath /dev or /devices
(e.g., it can't make links to them), and that these restrictions would be
extended across both fork() and exec(), what other holes do you see?

We have some commercial customers doing this for some Solaris boxes
connected to open public networks.  Does anyone have an idea about what
else they should be restricting?

paul

---------------------------------------------------------
Paul McNabb                     Argus Systems Group, Inc.
Vice President and CTO          1809 Woodfield Drive
mcnabb () argus-systems com        Savoy, IL 61874 USA
TEL 217-355-6308
FAX 217-355-1433                "Securing the Future"
---------------------------------------------------------