Isolating file system

[stream]

Hi,

This is a basic unix/freebsd question. Am on freebsd 12.

and have two users- say A and D both of them superusers.
D is a diagnostic account, and I need to share its login and pwd with an external party which does IT support.

is it possible to setup group priviliges in order to completely isolate files of A from D- so A files are protected from reading or copying from D.

Thank you.

 

[wolffnx]

I think that with correct permisions trough chmod you are done

 

[ShelLuser]

and have two users- say A and D both of them superusers.
D is a diagnostic account, and I need to share its login and pwd with an external party which does IT support.

is it possible to setup group priviliges in order to completely isolate files of A from D- so A files are protected from reading or copying from D.

Impossible to fully answer without further context. Basically: super user aka root is just that: a user which can do everything on a FreeBSD system, this automatically includes (file) access.

So no, unless you move one account into a Jail of some sort (maybe a chroot environment?) I don't see this working out. The best you can hope for is security through obscurity, which basically isn't much secure at all.

 

[ralphbsz]

You said "both are superusers". In Unix, there is only one kind of superuser, and that is root. Are you saying that the user-ID of "D" is 0?

In that case, you can not protect against D doing pretty much anything, as they can do everything that A can do. For example, you can use chmod and chown to make files completely unreadable, but root is not bound to normal access controls:

# This example is running as root.
# cat > /tmp/foo
sdjgfsdjfgsdjgfdsjfg
# chmod 000 /tmp/foo
# ll /tmp/foo
----------  1 ralph  wheel  21 Nov 11 12:49 /tmp/foo
# cat /tmp/foo
sdjgfsdjfgsdjgfdsjfg

There are some things you can do. You can for example declare files to be completely unchangeable and undeletable, by using the schg flag (which is supported by both major file systems on FreeBSD), and then set the kernel securelevel up so nobody, not even root, can override schg flags (do man chflags and man securelevel). But: Nothing prevents D from rebooting the machine at a reduced securelevel: if anyone can do it, D can do it, and D is root.

I think the solution has to be elsewhere: D can not be root. That immediately opens a question: What do they need to do on the machine? Normal non-root accounts are VERY restricted in what they are capable of doing. You could in theory spend hours tuning permissions, so D can do their tasks as a non-root user, but I don't think this is very realistic.

What this points out is a fundamental design flaw of Unix, which has been known for about 50 years now: Unix's permission model is very coarse, it only has three levels (root, user, everyone), and it has no mechanism for partial group-czar or root permissions. This is because Unix was at its core designed to be an OS for a group of friendly computer science researchers, and the concept of "root" was intended to guard against fat-fingering, not against malice. Other OSes created at about the same time (such as VMS, and MVS with RACF) had much more complicated permission systems. For example on VMS, you can mark users as being "group czar", meaning they can do anything that root can do but only within entities (files, devices, quota) that's owned by their group. And you could mark users as "operators", which could do things like mount devices, perform other maintenance operations, and perform backups (which means they can sort of read all files), but they can not actually access resources (such as other user's files) except through opaque channels such as the backup system.

 

[stream]

Impossible to fully answer without further context. Basically: super user aka root is just that: a user which can do everything on a FreeBSD system, this automatically includes (file) access.

So no, unless you move one account into a Jail of some sort (maybe a chroot environment?) I don't see this working out. The best you can hope for is security through obscurity, which basically isn't much secure at all.

Thanks. What context do you need. I just want to make sure that all files and data are completely hidden and inaccessible from a root user. I tried various things- but as root D can somehow get into A account.
Ideally I would like to setup a virtual system for D, so that they can change anything at the system level- /etc sysctl etc, but should not be able to access /ust/home/A

 

[stream]

You said "both are superusers". In Unix, there is only one kind of superuser, and that is root. Are you saying that the user-ID of "D" is 0?

In that case, you can not protect against D doing pretty much anything, as they can do everything that A can do. For example, you can use chmod and chown to make files completely unreadable, but root is not bound to normal access controls:

# This example is running as root.
# cat > /tmp/foo
sdjgfsdjfgsdjgfdsjfg
# chmod 000 /tmp/foo
# ll /tmp/foo
----------  1 ralph  wheel  21 Nov 11 12:49 /tmp/foo
# cat /tmp/foo
sdjgfsdjfgsdjgfdsjfg

There are some things you can do. You can for example declare files to be completely unchangeable and undeletable, by using the schg flag (which is supported by both major file systems on FreeBSD), and then set the kernel securelevel up so nobody, not even root, can override schg flags (do man chflags and man securelevel). But: Nothing prevents D from rebooting the machine at a reduced securelevel: if anyone can do it, D can do it, and D is root.

I think the solution has to be elsewhere: D can not be root. That immediately opens a question: What do they need to do on the machine? Normal non-root accounts are VERY restricted in what they are capable of doing. You could in theory spend hours tuning permissions, so D can do their tasks as a non-root user, but I don't think this is very realistic.

What this points out is a fundamental design flaw of Unix, which has been known for about 50 years now: Unix's permission model is very coarse, it only has three levels (root, user, everyone), and it has no mechanism for partial group-czar or root permissions. This is because Unix was at its core designed to be an OS for a group of friendly computer science researchers, and the concept of "root" was intended to guard against fat-fingering, not against malice. Other OSes created at about the same time (such as VMS, and MVS with RACF) had much more complicated permission systems. For example on VMS, you can mark users as being "group czar", meaning they can do anything that root can do but only within entities (files, devices, quota) that's owned by their group. And you could mark users as "operators", which could do things like mount devices, perform other maintenance operations, and perform backups (which means they can sort of read all files), but they can not actually access resources (such as other user's files) except through opaque channels such as the backup system.

Yes, only one root. I meant both have superuser privileges.
So, I have 3 users: root, A and D
All 3 have sudo rights.
I want A's files, data, various login files stored in text all to be completely hidden from D.

Thanks for the detailed explanation. Yes, that is the kind of thing I was looking for. Some sort of a semi-root (who will only access certain folders and directories). I have the server running in a colo facility. So I need to give login to them to access.

 

[forquare]

What this points out is a fundamental design flaw of Unix, which has been known for about 50 years now: Unix's permission model is very coarse, it only has three levels (root, user, everyone), and it has no mechanism for partial group-czar or root permissions.

Almost certainly not helpful to the OP, but IIRC the root user on Solaris 10 wasn't as all-powerful as root on previous Solaris versions thanks to RBAC. By setting up a new role one could get near root privileges but with certain caveats.

It's been a long time since I've touched any of that, and never done so on FreeBSD. Does FreeBSD's Mandatory Access Control offer anything similar to this, whereby D isn't UID 0, but has almost the same privileges?

 

[ralphbsz]

Does FreeBSD's Mandatory Access Control offer anything similar to this, whereby D isn't UID 0, but has almost the same privileges?

The problem is: If D is not root (does not have user-ID == 0), then how do you allow them to do common administrative functions? Such as reboot, halt, change sysctl settings, change network settings (ifconfing), update config files (like changing the IP address in /etc/rc.conf), allow them to mount and format disks? How about installing new software, perform software upgrades? Most of these things today are implemented simply by checking whether the effective UID of the running process is zero.

Concrete example, given the OP's situation: Assume that they get a new UPS delivered. The new UPS is made by APC (I'm just using that an example, not as a ringing endorsement of APC gear), so D has to install the apcupsd package, configure it (edit files in /etc/), and connect it to a web page (edit the Apache server directories), and modify the system startup/shutdown scripts (I'm not 100% sure all of these steps are necessary). That means that D needs pretty much unfettered access to the whole file system.

One way to handle this: think of all possible tasks that D needs to do. For each of them, write a script or program. In most cases, those can be short 3-line scripts, or they can be individual commands. For example, if D has to be able to shut the system down, they need to be able to execute the "halt" command. If it is with parameters (in the form shutdown -h now), then create a script called /usr/local/sbin/D_halt that contains just that line. Then for each possible action, create an entry in sudo. Make D a normal user, but configure sudo (or it's more modern successor doas) so D can do exactly what they need to do, no more. This is in reality completely impractical, since writing all these scripts and the sudo/doas config file is a HUGE amount of work. And you never know what D needs to be able to do until the "shit hits the fan" and you figure it out the hard way.

Honestly, I don't know a good solution.

 

[ralphbsz]

I have the server running in a colo facility. So I need to give login to them to access.

I presume that D is part of the staff of the colo facility. In that case, they already have full access to the machine. All they need to do is to walk up to it, plug in a keyboard and monitor, hit the reset button, and start it in single-user mode. At that point, they can do absolutely everything, including reading every single bit on disk. The only thing that will save you against that is: you configure the storage (either disk drives themselves in hardware, using SED, or the file system) to be fully encrypted, with the encryption key under your control (like you have to enter it after every reboot). Similarly, a person that has physical access to the machine can use the same technique to modify any configuration.

Now you could argue: "But I will notice that". Are you? Imagine this scenario: your colocated server crashes. It comes back up an hour later. You call the colo facility, they go "we're very sorry, we had a power outage and then one of our techs tripped over a cable and unplugged it, we'll credit you for the hour of use you didn't get". Unbeknownst to you, during that hour they disconnected the network from the machine, started it in single user, and added one line to /etc/passwd, creating a new user (for which they have the password) that they will use to spy on you. If they are good at what they do, they even modified the cached copy, so the normal nightly security run won't notice.

They also have the power to destroy your machine. For example, pull it from the rack, and put it in a 55-gallon drum of acid and dissolve it (that's meant as a joke, it's the scene from "who framed roger rabbit" where the characters are dissolved in an acid-like fluid). Sure, you would notice it after the fact. But what are you going to do? Sue?

The truth is: Once you give someone physical control of the hardware, you have to trust them. If they say that they need to be able to log in to your machine, either give it to them *AFTER* ensuring that they are trustworthy, or find another colo facility, or do a lot of work to harden your system.

 

[ShelLuser]

I just want to make sure that all files and data are completely hidden and inaccessible from a root user. I tried various things- but as root D can somehow get into A account.

Yah, that concept is not going to work.

Ideally I would like to setup a virtual system for D, so that they can change anything at the system level- /etc sysctl etc, but should not be able to access /ust/home/A

That's probably your best bet: a virtual filesystem (maybe encrypted through ELI?) for which one user has the key (password) while the other doesn't. Of course this isn't full proof. I'm probably taking things a but too far but theoretically the other user could copy the whole image and then try to take a crack at it that way. Use dd(1) to make an image file, use mdconfig(8) to make this available as a block device and then use geli(8) to encrypt it. Once set up you use newfs and mount to gain access and move your stuff in there after which you're pretty much done. If you use a keyfile and keep this offsite you'll severely limit any chances of gaining access.

Or a jail, but then we're coming back to the context I mentioned earlier: if they're going to do support you probably want them to have full access to your system, so this is likely not a feasible solution. Still... what kind of support are we talking about anyway? I mean.. database support doesn't need full root graded access.

 

[_martin]

As anonymous9 metioned, root is root, even under Solaris. RBAC is very nice feature indeed, if you're interested check the Solaris RBAC docs. Not applicable to FreeBSD though.

stream: what do you consider superuser to be ? Note having "sudo rights" doesn't necessary mean root access.

It seems you don't want remote IT support to read your files. If A and D both are root (their uid is 0 or they have ways of elevating to uid 0) you can't hide your files the standard way (permission, ACL..).

 

[rootbert]

one idea: ssh-chroot users and use mount_nullfs to mount the respective data into the chroot

 

[facedebouc]

There is also sysutils/pefs-kmod to encrypt respective files and directories.

 

[wolffnx]

and have two users- say A and D both of them superusers.

sorry, I dont read this
I retract my answer… you can do nothing,or both are normal users managed by root or not
simple as that