Hi. First of all: Thank you for your answers to my question relating the security of a chrooted environment. I just called the provider of the system working with the descripted chroot jail. He told me that inside the jail theres only one program with suid root bit set, namely crontab. No UID/GID is changed during "chrooting" and all programs inside the jail are unchanged copies. So every process executed from inside the jail runs chrooted too with its normal rights. Based on these statements, he estimates his system secure. My knowledge of hacking is quite small so i can't decide if he's wrong. There is another solution of locking a user in a private environment by starting some tasks delusioning a complete hardware environment with own IP and running a second complete Linux inside this environment (seem to be very complex, but works pretty nice). IMHO the safer solution. If a hacker tries to break up these tasks he cuts his own (virtual) kernel and (for my personal view) will be cut off from the connection immediately. Am I wrong? * * Ralf 'coko' Koch * mailto:info@formel4.de * --- Computers are like air conditioners: They stop working properly if you open windows.
There have been root hacks in crontab before. There likely will be some in the future too. Kurt Hi. First of all: Thank you for your answers to my question relating the security of a chrooted environment. I just called the provider of the system working with the descripted chroot jail. He told me that inside the jail theres only one program with suid root bit set, namely crontab. No UID/GID is changed during "chrooting" and all programs inside the jail are unchanged copies. So every process executed from inside the jail runs chrooted too with its normal rights. Based on these statements, he estimates his system secure. My knowledge of hacking is quite small so i can't decide if he's wrong. There is another solution of locking a user in a private environment by starting some tasks delusioning a complete hardware environment with own IP and running a second complete Linux inside this environment (seem to be very complex, but works pretty nice). IMHO the safer solution. If a hacker tries to break up these tasks he cuts his own (virtual) kernel and (for my personal view) will be cut off from the connection immediately. Am I wrong? * * Ralf 'coko' Koch * mailto:info@formel4.de * --- Computers are like air conditioners: They stop working properly if you open windows. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
I totally agree, but I think that's a general problem of all Linux versions including chrooted Linux cages. I searched Bugtraq for chroot exploits and just found 2 messages. The first from 1991 isn't really interesting. The second one discusses the knowledgement of being on server root or on virtual root which MIGHT be a starting point for hackers to break the chroot jail. I have not found a message dealing with a breakable chroot environment - except ftp faults (wu-ftp) during their attempt to create perform a chroot. Ralf
There have been root hacks in crontab before. There likely will be some in the future too.
Kurt
Hi.
First of all: Thank you for your answers to my question relating the security of a chrooted environment.
I just called the provider of the system working with the descripted chroot jail. He told me that inside the jail theres only one program with suid root bit set, namely crontab. No UID/GID is changed during "chrooting" and all programs inside the jail are unchanged copies. So every process executed from inside the jail runs chrooted too with its normal rights.
Based on these statements, he estimates his system secure. My knowledge of hacking is quite small so i can't decide if he's wrong. There is another solution of locking a user in a private environment by starting some tasks delusioning a complete hardware environment with own IP and running a second complete Linux inside this environment (seem to be very complex, but works pretty nice). IMHO the safer solution. If a hacker tries to break up these tasks he cuts his own (virtual) kernel and (for my personal view) will be cut off from the connection immediately.
Am I wrong? crontab might be a problem. I consider crond runs out of jail. If the user can place entries to
On Wed, 6 Dec 2000, Ralf Koch wrote: the crontab file (depends on which crontabfile cronds uses) (s)he can break out. Sebastian
participants (3)
-
Kurt Seifried
-
Ralf Koch
-
Sebastian Krahmer