# Securing data with jails



## xy16644 (Aug 12, 2014)

I have two ZFS pools in my server: zroot and zstore. The zroot pool has my root on ZFS and zstore is used (currently) for my backups. My server is used as an email server with HTTPS, SMTP(S), SSH and IMAPS ports published to the internet on a static IP address. 

In the future I may want use the zstore pool to store a copy of my personal data so that my data is on ZFS and I can take advantage of checksums, snapshots etc. The concern I have is, if someone hacks my server they could get access to my personal data. So, would having a jail help in this situation? (I have never used or worked with jails) Would (or could) my data sit in a jail that is secure from the host server if it is hacked?

If have a jail called DataBackup that is in the following directory: /zstore/jails/DataBackup and the host gets hacked, would they be able to view or gain access to the data I have in the jail?

Thanks!  :stud


----------



## SirDice (Aug 12, 2014)

xy16644 said:
			
		

> Would (or could) my data sit in a jail that is secure from the host server if it is hacked?


No, it's not. The host can access _all_ filesystems, including those of the jail. The other way around however would be protected. The jail can only access filesystems it has been assigned to, it cannot access filesystems outside it. So if the jail is hacked the rest of the host (and the other jails) would be protected.



> If have a jail called DataBackup that is in the following directory: /zstore/jails/DataBackup and the host gets hacked, would they be able to view or gain access to the data I have in the jail?


Yes, they would.


----------



## xy16644 (Aug 12, 2014)

I thought that was the case, thanks for confirming that!


----------



## ta0kira (Aug 22, 2014)

I've been trying to figure out how to do this for over a year, even without using ZFS. I've decided that it's way too painful to attempt to fully prevent a rogue root process from reading certain data; that would essentially involve locking your system down to a point that you can't effectively administer it. Basically, FreeBSD isn't designed in a way that you can fully prevent read access by a root process without jailing it. Even if you use mac(4), there is no way to fully prevent access by a root process unless that process is jailed, due to the way devfs and ZFS deal with /dev MAC labels.

If you want to simply limit access by users who are normally able to see that data (e.g., by an intruder with a stolen password), your best bet is to create a special user group for users who can access certain data, and update /etc/login.access to limit where people in that group can log in from. You could even create a special user that has exclusive access to that data, and restrict logins for that user to local logins only, e.g., -:secretuser:ALL EXCEPT LOCAL in /etc/login.access. Of course, you'd also need to really limit where users who can sudo(8) can log in from. (You could enhance this with mac_mls(4), but it's a little complicated.)

As a last resort, if the data is so important that you absolutely never want anyone to see it, but for some strange reason you want it on a machine that runs network services, you could enable ATA security (assuming you have a spare SATA drive) with a password that isn't stored on the machine, and keep it locked except when you need access to the data. That could be a bad idea, however, because I don't think FreeBSD responds well to a hard drive completely ignoring read requests.

Kevin Barry


----------

