Hi,
I am just looking for some confirmation that my custom chroot-jail is indeed secure and locked away. The server is an educational server that I manage for the Computer Science department at the University I work for. The script in question is a simple IM server that listens on port 5190, it's written in Java. I didn't feel comfortable just allowing that process to reside on the local filesystem with knowing that it may be full of buffer problems etc. Since this is my first time doing this from scratch, and I know that chroot jails can be broken if setup incorrectly, I thought I'd seek some confirmation that this is securely setup. Any feedback on my setup is greatly appreciated!

The Chroot Environment:

I've developed the jail environment in /var/jail. Within the environment are needed java libraries as determined by ldd, strace, and strings. The only binaries in the environment are /bin/bash, /bin/su (not suid, self compiled version that doesn't use pam), /usr/bin/java, and their server classes/binaries. The environment is owned by root, with the exception of a different group for /opt/IM_Server which is group writeable to allow the students to modify the code as needed. /etc/passwd contains only the user that the process will run as, /etc/shadow contains a !! password for the user in question, /etc/group contains the group for the unprivileged user and the group that should have write access to /opt/IM_Server. There is no root user in the environment.

Entering the Environment and Starting the IM_Server:

To accomplish this I've created a sysv init script that issues the commands:

When starting:
When stopping:
The contents of the /etc/init.d/ServerScript mentioned above are:

The idea behind the script is it enters the environment as the jail user, starts the java Server instance, and then leaves the environment so that a shell isn't left running.

To allow the students access to restarting the server when they've updated code, I added the necessary students as sudoers, allowing them to only stop, start, and restart the IM Server:

So, the sysv init script works fine, the Server is listening on port 5190, and an lsof | grep JavaServer shows that it's only accessing files in the jail environment and nothing else. My question is, does my setup look secure, if somebody compromises the IM Service are they really locked in a jail, and are there any ways of confirming the presence of the jail environment since an lsof shows the full path to the files not relative to the jail root? Some other questions are, how do you guys suggest I maintain updated libraries and binaries in the jail environment, and is there anyway to prevent users from binding processes to network ports? The second half of that question concerns preventing the students from being able to run the IM Server outside of the jail; right now they can start the server and it binds to port 5190 without problems (I see this as bad). Please don't hesitate to tear my setup apart, I want this to be bomber.

Thanks!
Mike.

I'm really not a dev or a hacker, but:
-Indeed, jails can be broken.
-Using java is a bad idea (imho), as virtual machines are a treasure for someone who wants to do evil things without beeing detected.
-Jabber exists: http://www.jabber.org/

Thanks for the response. However, as I said in my post, this is an educational server. The IM server is written by students learning Java. Whether or not a package already exists to do exactly what they are trying to do (jabber), or whether or not Java is a bad idea, is beyond the scope of this discussion.

My goal is to secure the system as well as possible while enhancing the educational experience. It is my responsibility to ensure that the server is configured properly and securely, and maintained at high enough standards to atleast make a break in difficult. With this in mind, I am still curious as to whether or not people think the setup I've described is a solid brick of cheddar, or more along the lines of swiss cheese... Thanks!

have you looked into grsecurity?? http://grsecurity.net/

That looks handy, and I will definitely look into it, but it's a little much for what I'm looking to accomplish right now. Although I have a place for that on another server. Thanks!

When stopping: Code: PID=`/bin/ps ax (...)
Of the escape routes /proc is one. Other ones are access to /dev/kmem and setuid binaries, see the popular http://www.bpfh.net/simes/computing/chroot-break.html . With the GRSecurity patch you can cover all of them (though I can't remember if making kmem read-only breaks Java: look it up). You can even allow /proc to be mounted and the user will only see process data that relates to its own uid.


are there any ways of confirming the presence of the jail environment
Run this inside the jail: http://www.linuxquestions.org/questi...84#post2167284


how do you guys suggest I maintain updated libraries and binaries in the jail environment
Should be easy to run a post-upgrade script that flags for stuff to copy. Since it's a jail you don't want to trade off security by automating stuff too much I guess.


is there anyway to prevent users from binding processes to network ports?
That's another GRSecurity feature.


I am just looking for some confirmation that my custom chroot-jail is indeed secure and locked away. / Please don't hesitate to tear my setup apart, I want this to be bomber. / That looks handy, and I will definitely look into it, but it's a little much for what I'm looking to accomplish right now.
I don't think you appreciate what GRSecurity can do for your setup. Using GRSecurity to reinforce chroots, gain access to extended logging and usable restrictions (even if you choose to leave out PAX, RBAC or munging /dev/kmem) is by far the easiest way to go (as in unfair comparison to SELinux/Xen/Vserver/UML/whatever else).

Thanks for the information UnSpawn! I will invest some more time in looking into grsecurity. The network port binding is an important one, and it sounds like it will just make my life easier overall.

About my current setup, since the sysv init script is calling:

Outside of the environment (it doesn't exist in the chrooted environment), is this a security problem? Proc is not available in the environment either, and I don't have any suid bits set on the files. I recognize that I'm using back ticks here, but there is no user input, and the worst that I can see happening is a user killing another process that looks like "java Server" which I'm not worried about right now; then-again, the worst I can see is a very limited scope in comparison to any cracker out there... Thanks again for working through this with me guys, it's been very helpful!

Mike.

since the sysv init script is calling (..) outside of the environment
Sorry, misread that for being inside of the chroot. Not a problem, no.