At Tue, 30 Jan 2024 16:19:31 +0100, tlaronde%kergis.com@localhost wrote: Subject: Re: Reverse of promoting to root: downgrade root to unprivileged > > On Tue, Jan 30, 2024 at 02:35:02PM +0100, Rhialto wrote: > > On Mon 29 Jan 2024 at 15:23:24 +0100, tlaronde%kergis.com@localhost wrote: > > > The typical example is say, with pkgsrc (or any kind of packages > > > system). One wants to build unprivileged, but installation may be > > > privileged. So instead of running as non root and having to enter the > > > password each time the installation of a dependency requires it, one > > > starts as root, but the privileged rights are only used when needed. > > > (I know that one can build in a chroot unprivileged and so. > > > The curiosity is to know if another way to achieve things has been > > > attempted.) > > > > This can also be done with sudo (or su), just with the sudo calls placed > > in different locations. That is what the sudo -u parameter is for. As > > long as the granularity is on process level, su (or sudo) could do it. > > That something can be written is sure. But I wondered if there was > some attempt of some library (in whatever language) or some utility > that will "fence" a root user, and will, allow, without modifying > existing (say, as an example, using pkgsrc compilation and > installation procedure), to downgrade root for running and, when > hitting the fence (trying to transgress the rights), will consult a > list of commands---may be script lines: "make install"---and then > respawn the part with updated rights if the commands were listed. I'm not sure where the complexities are that would require more than one call (either to setuid() or su, etc. depending on the implementation details such as programming language). Everything else is terribly application specific, so no matter what you do you have to figure out where to put that call. Note that in the Unix system model there's really only ever one truly privileged user, i.e. root (secmodel_suser(9), and secmodel_bsd44(9) adds some more features to sometimes restrict even root). All other "privileges" are fictions created by user-level programming and user-level system configuration and are not part of the kernel's security model. Typically with system programs and daemons there's generally only one time early in startup where privileged operations are required (e.g. a nameserver), though a classic example which adds a kink in the plan is email handling. Modern email systems typically have to listen for connections on a privileged port (25), but most of the process of accepting, queueing and routing of messages can be done without special privileges and so modern mailers run as a private unprivileged user, e.g. "postfix" to do those operations. However if local mail is to be delivered to old-fashioned mailboxes in /var/mail then once again privileges are required to open and write to the user's mailbox file, typically as that user. So this is done by a special separate setuid-root program (mail.local(8)) that has this one specific job to do and so it can be a small easily audited program. On the other hand to take the example of building packages, well there's where things get turned on their head. The historic response was to start and run the process as an unprivileged user and then to ask the human for privileges for the step or steps where they might be required (I added an audio message via PRE_ROOT_CMD to tell me to type the root password to install the next package). Unfortunately for package building though this has historically involved running third-party code with full root privileges, and even if we trust that code we can't necessarily always predict what operations it might want to carry out in a detailed enough way to say narrow it down to a specific set of programs with a specific range of parameters (e.g. that could be coded into sudo's configuration file). So more modern versions of pkgsrc (specifically pkgsrc) take back all control over privileged operations again and put them in the hands of one privileged program: pkg_add. Binary package archives can be created entirely without privileges (even if they install setuid-root programs) and only the final "install" step requires privileges. (See the *_PERMS variables in pkgsrc, eg. SPECIAL_PERMS) So in a "sandboxed" build one can build binary package archives entirely as an unprivileged user, i.e. with the help of a privileged "overseer" process which creates and configures the sandbox by installing whatever dependencies are required to build the next package and so on. I don't think pkgtools/pkg_comp does unprivileged builds yet because the machinery for installing pre-requisite packages still runs through the "make build" phase, but if this were split out then it could be possible to add this feature to pkg_comp. You'd need another general pkgsrc makefile target to get the list of dependencies in the correct order such that they can be built and then installed in a sandbox from binary packages. The print-build-depends-list is close, but not sorted in the necessary order (and it currently includes verbiage just for humans). So, for pkgsrc, the library or tool you're looking for has its beginnings in pkg_comp, but there's still work to do. > The question arises when I asked (wanting to write something for my > own): OK, but _what_ unprivileged user exists that I can safely "su" > to and accomplish the unprivileged part as? "nobody" does not seem the > answer; "operator" neither. This opened a can of worm-questions ;-) Indeed, "nobody" has, or at least had, a very specific and singular purpose (though it seems some programs are misusing it now). Typically one creates a new user for each specific "unprivileged" operation or group of operations. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpQ9uc_BsLsV.pgp
Description: OpenPGP Digital Signature