Solved How Secure Are Jails?

Hi,

as far as I know, all jails are being run by root. So, what happens if an attacker takes over one jail by exploiting MTA or apache? How easy is it to break out to host os?

I think it is little arrogant to say that jails are secure and we all are safe, right? ;)
 
as far as I know, all jails are being run by root.
Jails run inside a separate (kernel) namespace. So 'root' inside the jail is not the same as 'root' on the host (the jailed 'root' runs in a different namespace).

So, what happens if an attacker takes over one jail by exploiting MTA or apache?
They'll have mail or www access in the jail.
How easy is it to break out to host os?
I'm not going to say impossible, just very difficult to do. That's the whole point of the jail in the first place, if it was easy to circumvent it would be useless. Enabling things like shared memory and enabling direct access to disks for example would lower the security. But on a "plain" jail, it's very difficult to break out of it.
 
One pitfall would be to have a regular user that had access to the filesystem in the jail rooted directory (with the filesystem mounted without the nosuid option). Then the root on the jail could mark an executable with the setuid bit, and then the regular user on the host would be able to do a privilege escalation.
 
One pitfall would be to have a regular user that had access to the filesystem in the jail rooted directory (with the filesystem mounted without the nosuid option). Then the root on the jail could mark an executable with the setuid bit, and then the regular user on the host would be able to do a privilege escalation.
So, rather give jails dedicated zpools or zvols or image files? what's "best" for security? I guess image file are slow.
 
I there any possibility to kill a jail when it has been cracked? :-/ but how to scan from outside the inside the jail? maybe jail termination is possible from within by restarting jail and revert to last snapshot on zfs volume? :-/
 
You can’t “kill” or “turn off” a jail. It’s a system call; an integrated part of base itself. You’re making a lot of assumptions about it’s behavior here.
 
You can’t “kill” or “turn off” a jail. It’s a system call; an integrated part of base itself. You’re making a lot of assumptions about it’s behavior here.
I have no idea about jails, but I would like to know, whether it is possible to shut one jail down on corruption. When you start a jail you don't run it until inifity, do you? :what: ;)
 
You can’t “kill” or “turn off” a jail. It’s a system call; an integrated part of base itself. You’re making a lot of assumptions about it’s behavior here.
The main problem is that no system is invulnerable. I am wondering, if virtual machines (esxi) are safer than jails on freebsd. You guys have the experience, so I am asking you.
 
You would need to find a vulnerability deep in the kernel in order to ‘break’ a jail. Thankfully Jails has had over two decades to mature. So it’s highly unlikely.
 
You would need to find a vulnerability deep in the kernel in order to ‘break’ a jail. Thankfully Jails has had over two decades to mature. So it’s highly unlikely.
Sounds good to me, but does the community perform an ongoing quality check? :-/ How many security issues have occured during last time regarding jails?
 
Is there any bounty bug hunt or something that might rise people's motivation to find attack vectors on jail?
 
You would need to find a vulnerability deep in the kernel in order to ‘break’ a jail. Thankfully Jails has had over two decades to mature. So it’s highly unlikely.
I know FreeBSD is maturing like wine, windows like milk. But maturing is no garantee for a safe system. Windows is older than FreeBSD and it is still crap (not only from security perspective). Windows is also few decades old and people find still find bugs that have been inherited since the very early days (BTW this shows us that M$ is selling same OS to us the from begining:

Wiki:
... MS-DOS + Win3.11 + few cosmetics + few features + bugs = Win95a
... Win95a + few cosmetics + few (copied) features + bugfixes + new bugs = Win95b
... Win95b + few cosmetics + few (copied) features + bugfixes + new bugs = Win95c
... Win95c + few cosmetics + few (copied) features + bugfixes + new bugs = Win98
... Win98 + few cosmetics + few (copied) features + bugfixes + new bugs = WinMe
...
... WinNT4 + WinMe + few cosmetics + few features + bugfixes + new bugs = Win2000
... Win2000 + stolen technics from other OS' kernels + few cosmetics + few features + bugfixes + new bugs = WinXP
... WinXP + few cosmetics + few features + bugfixes + new bugs = Win7
... Win8 + few cosmetics + few features + bugfixes + new bugs = Win8
...
This is the stacked- 💩 strategy of M$. And if there is a bug in rpc, it suddenly threatens all windows systems across the product line.

I may sound like a M$ hater, but I am not ;) I just don't like them 😁
 
Regarding security checks. Yes.

Again, it’s a kernel level interface. It’s been ’checked’ for almost two decades now. Security is literally it’s constraint. It‘s nearly impossible to break a jail without panicking the system.

Is there any bounty bug hunt or something that might rise people's motivation to find attack vectors on jail?

What acumen do you even have to question the security of jails? Any solid hypothesis for your preconceived notions? This whole thread is quite embarrassing.
 
Back
Top