Re: Operator, Information, give me geom.ctl on the line

Shawn Webb <[email protected]> Wed, 29 Jul 2026 18:20:17 +0000
Newsgroups gmane.os.freebsd.current
Message-ID <ampAVyg4-adoVXCP@mutt-hbsd>
--ugzoaofg6bvqka3j
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: Operator, Information, give me geom.ctl on the line
MIME-Version: 1.0

On Tue, Jul 28, 2026 at 07:57:50PM +0000, Poul-Henning Kamp wrote:
> I have been pondering this ticket for a couple of years:
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277228
>=20
> The short version of the story is that:
>=20
> 	crw-r-----  1 root operator 0xa Jul 28 15:47 /dev/geom.ctl
>=20
> allows anybody in the operator group to issue ioctls, which, for
> instance, can nuke all partitioning from a disk.
>=20
> Kyle, Warner and I agree that:
>=20
> 	crw-r-----  1 root wheel 0xa Jul 28 15:47 /dev/geom.ctl
>=20
> Would make more sense, but we have no idea if, or to what extent,
> anything depends on operator issuing geom ioctls.
>=20
> The plan, such as it is, is to make that change in current to find out.
>=20
> Before I do that, I want to give any interested parties a chance to
> sandbox it for themselves, all you have to do edit geom_ctl.c
> and change:
>=20
> 	void
> 	g_ctl_init(void)
> 	{
>=20
> 		make_dev_credf(MAKEDEV_ETERNAL, &g_ctl_cdevsw, 0, NULL,
> 		    UID_ROOT, GID_OPERATOR, 0640, PATH_GEOM_CTL);
> 	}
>=20
> To GID_WHEEL instead.
>=20
> If I receive no emails indicating disasters, I will make the change in
> current in a couple of weeks, and wait for fireworks.

I would be happy to test out not only GID_WHEEL, but also 0600. If you
want a wider testing audience, I can commit the change and have
HardenedBSD users help test.

I noticed FreeBSD just pushed some security advisory fixes, so I might
make the change on HardenedBSD's side regardless and include it in the
next build I'll do after I address those fixes downstream.

> That way lies GID_BIKESHED.

I don't have any strong feelings on what it should be if it changes,
but GID_WHEEL does seem logical to me. Though, if the permissions are
changed to 0600, the GID doesn't really matter.

I wonder if there are accounts that are members of operator but not
wheel. Server accounts get added to the wheel group. So changing it to
GID_WHEEL without including the permissions change opens up the same
issue to server accounts (huge caveat: on my servers, though I suspect
plenty of others are in the same boat.)

>=20
> We also have devfs(8) and devd(8) now.
>=20
> Given that the vast majory of all FreeBSD systems are single user,
> or more likely "no-user", how many of them actually have any users
> in the "operator" group, besides "root" ?

The main account on pretty much all my laptops is a member of the
operator group. Mainly just so I don't have to type my password when I
want to shutdown from a terminal.

Server accounts do not get the same treatment, just laptop accounts.

Thanks,

--=20
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Signal Username:  shawn_webb.74
Tor-ified Signal: +1 (719) 756-1197 / activist_opsec.27
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A=
4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

--ugzoaofg6bvqka3j
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEEA6TL67gupaZ9nzhT/y5nonf44foFAmpqRFEbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwzAAoJEP8uZ6J3+OH6gT4P/3lJP9CDobzo9fJQWNLo
zPDFZD/ZDAEa0RKQeaKLBarrcEtDw45tHCJ6nK0LYK22E7oOIFlr9SQKxfEMM5pC
lbnq7jeRfORoLsbcAX9qI4f4qiayBhOsPXnio+X2ga14GY8I6q816bfQo0TEL9F8
cDDgVnhaIL12QYitu70tIORcVfvU/IkaWROYKEp4HMTGEUDuJxhhJWTWUKstVaBu
tzBNJp5NG8savNoynMfOT+AC/tM6jf4ECIliqTm4mQtxbrkD5qnDDqgJyNKJsJoX
T8PJ6lXXZyNoEppoIZ/neFaKpW6hsxCrmC0FFdoT6cxMoBIU2nu66Wp7dxYF5tzc
j4wpWUgEK6XGCb/bHseNSN7Fb6IXEJhgtrVEovQrC6luNwftSk7YQhB3JK9SyH0/
LFNB5939dXEbO/B8jyvo+Y4P6TMeV6I5B9R/k8+69MMx8bGAvwJs0Ne+Figs4tgK
ubJOTqpzK3vqW74EympxqggyLwMMrdfeBCCEW5m7aJ1iFLN2mTor9PGS2P0RanBO
n2Otl36DgZSbuKIdUGeAH1uJuWQGtq1hz1zjX0rnLP3B/D+mS/p2wqddbn4L3hbi
zq0WB2J7rPeVQdhLuqh93evV2LBcN1ca4mDUNkGesMFpdKrTn+YbrK8yr11RFdtg
CW1chjmoMPYyZtL4d/mgGo+e
=i0Wz
-----END PGP SIGNATURE-----

--ugzoaofg6bvqka3j--