gpart device permissions security hole (/dev/geom.ctl)

V

vstemen

Hi.

In the process of writing some systems administration tools on FreeBSD 13.1-RELEASE to custom partition drives and setup computers for our network and our customers, I have discovered that any user belonging to the 'operator' group has the power to completely delete the partition table and wipe out the whole system, just because the drive devices belong to that group, even if there is no read or write access to the devices by the group. I had to do a lot of research to find out, via mention on the freebsd irc after I asked and had considerable discussion, that these permissions are granted by just having read access for the group for /dev/geom.ctl. I found no documentation in general searches explaining this and no mention of it in the man pages such as for gpart or geom.

It seems like a bizarre design choice to me. It is very counter intuitive to see devices that have no write access and even no read access, yet be able to do something as critical as delete the entire partition table by just belonging to the group.

I have been a Unix systems administrator for well over 35 years and It's not uncommon for administrators to belong to the operator group for restricted admin tasks. It is completely unexpected to discover the user can wipe out the whole system.

unix.stackexchange.com

What is the point of the 'operator' user?

Many un*x systems ship with a user account named 'operator'. What is the purpose of this account? Do some systems actually make use of this account, or is this more of a historical legacy? Have yo...
unix.stackexchange.com unix.stackexchange.com
... the user operator on UNIX systems was meant for doing low privileged administrative tasks (replacing tapes, backups, maintenance, etc.).
Click to expand...
The above link describes the purpose I have always understood and used the operator group for in a variety of different Unix systems during all the years I have been a systems administrator.

I have always thought that FreeBSD put high priority and great pride in the security of the system, but this as substantial security hole. I only discovered it by complete accident during the development of our in-house tools when I ran the scripts from my normal user account, which also belongs to the operator group, during testing, expecting to get permission denied errors, only to discover it successfully wiped out and re-wrote the partition table. Luckily I had specified my test device that was not being used on the live running system.

I don't know the rationale behind this design decision, and perhaps there are good reasons for it from certain perspectives, but whatever it is, it does not change that fact that it creates a massive security hole in FreeBSD that even the most seasoned systems administrator can easily and unexpectedly fall into.

Here are the default permissions for geom.ctl.
crw-r----- 1 root operator 0xa Nov 16 11:50 /dev/geom.ctl
Here are the default permissions for the devices.
crw-r----- 1 root operator 0x53 Nov 16 11:50 /dev/ada0
crw-r----- 1 root operator 0x55 Nov 16 11:50 /dev/ada0p1
...
This is not limited, of course, to the operator group. I can change the group on the drive devices to any other group that I am a member of and even remove read permission for the group on the drives and can still delete the partition table.

I have never seen such behavior in any other Unix environment.
 
vstemen said:
I had to do a lot of research to find out, via mention on the freebsd irc after I asked and had considerable discussion, that these permissions are granted by just having read access for the group for /dev/geom.ctl.
Click to expand...
Can you explain how this works? Given that a non-root process that is in the operator group can not write to the disk devices, and given that tools such as gpart are not suid, how can such a process modify the partition table?

In your discussions, did you hear about any justification for this?
 
Since the operator group had access to /dev/geom.ctl, it can issue GEOM_CTL ioctl. Thus it can do maintenance task such as modifying partition table, or use gpart recover.
However it cannot do a dd on the device.
If you want to have a user with little admin power, you can use the correct tools for it. Putting regular user in the operator groups just so they can power off the machine is not what can be called good security practice.
 
It would not be able to modify partitions that are actively mounted either. It seems like unwanted behavior altogether.
ralphbsz you can easily test:
Code: 
$ id
uid=1002(pwn) gid=5(operator) groups=5(operator)
$
$ ls -al /dev/nvd1*
crw-r-----  1 root  operator  0x5d Feb 19 00:23 /dev/nvd1
crw-r-----  1 root  operator  0x90 Feb 19 00:37 /dev/nvd1p1
$
$ gpart add -t freebsd-ufs -s 128M nvd1
nvd1p2 added
$

$ gpart show nvd1
=>      40  75497392  nvd1  GPT  (36G)
        40       984        - free -  (492K)
      1024    262144     1  freebsd-ufs  (128M)
    263168    262144     2  freebsd-ufs  (128M)
    525312  74972120        - free -  (36G)
$
But none of my systems have anybody but root in operator group (excluding this example).

I wonder about the justification too. It seems more like a side effect with the access to geom ioctl.
 
This has been asked in the past
I guess that if you are using it to manage backup, it make sense to be able to change the partition table when you add a new device.
Since it cannot change the partition table of mounted drive (if you did not change some default), I don't see why it is a security hole. The real security hole was to put a non admin in the operator group in the first place.
 
monwarez said:
Since it cannot change the partition table of mounted drive
Click to expand...
I think you mean to say "of a mounted file system". In that case, the behavior seems completely sensible to me.

The implementation is still a bit surprising: Say /dev/da9 currently has partitions /dev/da9p1 and da9p2, which are formatted and mounted as file systems. It also has free space. A non-root user in the operator group can create new partitions in the free space. I think they can not create file systems in the new partitions, nor mount them, since they don't have write permissions on the devices. In a nutshell, they can perform a denial-of-service attack by destroying usable free space.

What is surprising is this: While /dev/da9 is not writable by that non-root operator user, they were able to create partitions on there, which implies writing to the partition table.
 
ralphbsz said:
Can you explain how this works? Given that a non-root process that is in the operator group can not write to the disk devices, and given that tools such as gpart are not suid, how can such a process modify the partition table?

In your discussions, did you hear about any justification for this?
Click to expand...
No. There has been no mention of any justification for it. That is one of the things I have been trying to find out.
 
ralphbsz said:
I think they can not create file systems in the new partitions, nor mount them, since they don't have write permissions on the devices.
Click to expand...
If I speculate a bit, and this is far fetched I know. If there's a drive on a server where you regularly create a partition/FS and then destroy it (e.g. you create partition, have a scratch FS, then you remove it ) you could create a payload (blob of data (created and prepped as a root on other machine) that would give you root; as simple as 4755 on a shell). You could create a partition and align it to your file. But still you can't mount it.
Again, really far fetched scenario and the only one I was able to think of now.
 
monwarez said:
If you want to have a user with little admin power, you can use the correct tools for it. Putting regular user in the operator groups just so they can power off the machine is not what can be called good security practice.
Click to expand...
What other kind of user are you going to put in the operator group? All users other than root are regular users that are only granted permissions via owner and group permissions. That is the whole point of using groups to manage permissions. Otherwise you would just give them root access.

The way it is now, if I don't put users in the operator group, then they cannot partition flash drives.

With all drives controlled by the one group that the one geom.ctl file belongs to, please explain how you would give your secretary, for example, the ability to do this without giving her the ability to delete any partitions on any devices that happen to not be mounted.

Also, what do you mean by the correct tools? Different levels of admin power have always been controlled by user and group (and/or ACLs) permissions. Any tool I run is going to be running under those permissions.
 
You can use the example on the handbook
Code: 
[localrules=5]
add path 'da*' mode 0660 group operator
and transform it to
Code: 
[localrules=5]
add path 'da*' mode 0660 group flashdrive

You also can use tools like sudo/doas to allow specific commands in some case.
 
vstemen said:
No. There has been no mention of any justification for it. That is one of the things I have been trying to find out.
Click to expand...

On the surface I agree that this sounds surprising to alarming. I and most forum-level folk can offer opinions, no matter how experienced, but the notion that careful choice of who may be in group operator doesn't sound sufficient to me.

I suggest that you should submit this as a PR, so that heavy-duty filesystems and security team people will be alerted immediately. If not a PR, at least mail to secteam?
 
This was discussed on this forums previously
forums.freebsd.org

Groups Overview

I seem to fail at finding documentation regarding the "default", "built-in" or common user groups. Could somebody point me towards the right direction? The reason I'm asking this is because I came across the operator group when setting up a FreeBSD desktop machine. I have not encountered this...
forums.freebsd.org forums.freebsd.org
See https://www.oreilly.com/library/vie...06268/ch04.html#mfreeopenbsd-CHP-4-SECT-2.4.4
Filesystem access

On a typical server (either OpenBSD or FreeBSD), the raw disk devices are owned by root, but the group operator has access to read them. This allows the operator group to bypass the filesystem and its permissions and read raw data blocks from the disk. This is how dump is able to take a near image of a disk device. If you rebuild a filesystem with newfs(8) and then restore your files, the files will be restored almost exactly, down the inode numbers in many cases. The operator group is especially designed for backups this way. If you look in /dev, you will find that operator has read access to almost all significant raw data devices: floppy disks, hard drives, CD drives, RAID controller devices, backup tape drive devices, etc. Furthermore, the operator user’s account is locked down in a way that the user cannot log in. If you run backups, either by custom scripts or by Amanda, you should use the operator user and/or group. The default Amanda configuration will do just that.
Click to expand...
 
monwarez said:
You can use the example on the handbook
Code: 
[localrules=5]
add path 'da*' mode 0660 group operator
and transform it to
Code: 
[localrules=5]
add path 'da*' mode 0660 group flashdrive

You also can use tools like sudo/doas to allow specific commands in some case.
Click to expand...
Yes, I have already thought about sudo/doas as a work around, but again, one must be aware of this issue to know that this is necessary.

The suggestion you just gave me shows that you just fell into the very security trap I am talking about. In the section you are referencing, the handbook says "To make the device mountable as a normal user, one solution is to make all users of the device a member of the operator group". Yes, that is one of the purposes of the operator group. But what if fails to mention is that by doing so, you are giving the user the ability wipe out any partitions that are not mounted on all drives on the entire system because they are all controlled by one single file, /dev/geom.ctl, which belongs to group operator.

Second, changing it to group, flashdrive, does not work if you are trying to grant permission to partition the flash drive because, again, it is only possible if you belong to the same group as geom.ctl.
 
Last edited:
vstemen said:
Second, changing it to group, flashdrive, does not work if you are trying to grant permission to partition the flash drive because, again, it is only possible if you belong to the same group as geom.ctl.
Click to expand...
In this case you just don't use gpart to do the partitionning, thus no operator group needed.
With the localrules with the flashdrive group, the user can directly do a dd on the device.
Thus a partition table could be created (with dd).

If you need a finer control over what an user can do, then doas/sudo is the tools for the jobs.

Anyways,
Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view. Most file systems were not built to safeguard against malicious devices.
Click to expand...
Sure they don't go in detail to say that putting user in operator group is a bad idea.
 
smithi said:
On the surface I agree that this sounds surprising to alarming. I and most forum-level folk can offer opinions, no matter how experienced, but the notion that careful choice of who may be in group operator doesn't sound sufficient to me.

I suggest that you should submit this as a PR, so that heavy-duty filesystems and security team people will be alerted immediately. If not a PR, at least mail to secteam?
Click to expand...
I agree. I think I am going to do that.
 
smithi said:
I suggest that you should submit this as a PR, so that heavy-duty filesystems and security team people will be alerted immediately. If not a PR, at least mail to secteam?
Click to expand...
Well, I tried submitting a PR on bugs.freebsd.org but it doesn't seem to work.

After filling the rest out and entering text in the Comment field, when I click the Preview tab it just gives me a blank window in the preview area. Even with just a small paragraph. It does not seem to accept any of my text. I tried in both firefox and chrome browsers. Has anybody else experienced this?
 
vstemen said:
... entering text in the Comment field, when I click the Preview tab it just gives me a blank window in the preview area.
Click to expand...
"Preview" doesn't display always the comment text. I've seen it before using www/firefox (I don't know wich versions they where, at least 10 - 12 months older than now). All firefox versions profile had/have only KeePassXC-Browser addon.

Current Firefox I use, version 123.0,2, is affected as well, but only as a bug reporter. When text will be submitted as "Additional Comments", "Preview" does display it.

But that's no problem at all. The description text of the bug report in the comment text box, when submitted, will display the text, even when "Preview" is empty, at least last time I submitted a bug report it was, a year ago, or so. EDIT: On 2022-11-25 exactly.

EDIT 2: There is a open bug report regarding the issue (opened 2020-10-28):

Bug 250699 - Preview tab is blank for new issues
 
monwarez said:
Since the operator group had access to /dev/geom.ctl, it can issue GEOM_CTL ioctl. Thus it can do maintenance task such as modifying partition table, or use gpart recover.
However it cannot do a dd on the device.
If you want to have a user with little admin power, you can use the correct tools for it. Putting regular user in the operator groups just so they can power off the machine is not what can be called good security practice.
Click to expand...

I appreciate the explaination. It does seem very strange to me, however.

Shouldn't it check for write access to allow ioctl? At least that kind of ioctl -- not sure if others should be allowed like that.
 
If operator have write access to the device, then it does not need to use the ioctl: it could directly access the raw device.
Instead, by having read access, operator can dump the entire device for backup purpose and it can manage the partition scheme.
 
T-Daemon said:
Current Firefox I use, version 123.0,2, is affected as well, but only as a bug reporter. When text will be submitted as "Additional Comments", "Preview" does display it.

But that's no problem at all. The description text of the bug report in the comment text box, when submitted, will display the text, even when "Preview" is empty, at least last time I submitted a bug report it was, a year ago, or so. EDIT: On 2022-11-25 exactly.
Click to expand...
OK. I went ahead and posted a bug report a couple days ago.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277228
 
monwarez said:
In this case you just don't use gpart to do the partitionning, thus no operator group needed.
With the localrules with the flashdrive group, the user can directly do a dd on the device.
Thus a partition table could be created (with dd).
Click to expand...
Think about it. For one, where are going to dd from? You need a raw image that you have partitioned to dd from, to write it to the thumb drive. How do you get that without having some device that you can partition ahead of time to get the image of the sector. That would require belonging to the group of geom.ctl in order to create it.

Then, that would only work with MBR partitions, which we almost never use any longer. GPT partition tables have a backup partition table on the end of the device and they have CRC's to verify them. So, again, this would not work. Even if you had an image to dd from, you would get corrupt partition errors from then on without having group access to geom.ctl to run gpart to correct it.
 
I say it can be created, not that it is easy. You could create the partition by hand, and writing to the end of the disk can be done with dd (use the seek parameter).
I suppose that there exists somewhere a software that can mimic gpart operation on an .img file.
 
You must log in or register to reply here.
Back
Top