Re: Reverse of promoting to root: downgrade root to unprivileged

[tlaronde%kergis.com@localhost]

On Sun, Jan 28, 2024 at 04:17:11PM -0800, Greg A. Woods wrote:
> 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).
> 

In my case, the library is written (it is a POSIX.2 sh library used in
kerTeX for package handling) so I know where to promote.

I had written it being strict: if a program was run as root, it
stopped and ask to be re-run without being root, being promoted to
root with su(1) only when needed.

So I wanted to be smart enough, if run as root, to downgrade to some
user, and to re-upgrade only, if needed, when installing ("applying"
in kerTeX pkg lingo) or de-installing.

But then I stumbled upon the: which user? There is no standard user defined (in
whatever Unix OS) for this purpose so I would have to create one
specific at install time. And I'm reluctant to create a user for
kerTeX...

> 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.

Yes, but there is nothing scandalous about this: the kernel provides
"elements". There is one "atom" root, and one can combine this with
other bits to try to approach the "curve" of the needs.

A facility would be to be able to define groups with groups components
(in fact a "user" being only a singleton group).

Furthermore, logically, there is the real identity of the person
(for accounting purposes, including mistakes or misbehavior) and
the "logical" identity (the logical user on a node or in a network,
that has some rights and a define task to do). This is not directly
implemented, if I'm not mistaken, in any OS I know except as "this"
user and then belonging to this group, and the emphasis being on
groups (which doesn't seem natural, while this is logical).

> 
> 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.
> 

For the kerTeX package system, where, of course, I hit the same
problems, I realized that I could in fact build unprivileged simply by
manipulating environment variables to add resources provided by
dependencies built if asked to, simply by pointing to the temporary
directory where the hierarchy to install is built (the package only
tar'ing this sub-hierarchy).

It would be more difficult with pkgsrc I imagine, because it relies on
the pkgsrc database also to know what is installed and for which
version (or at least I guess it is sometimes used like that, not
everything providing pkgconf entries or variations).

There is always the brute force approach: creating an empty pkgsrc
database in the final target package workdir; create fake entries for
installed packages matching the requirements (manipulating env
variables to reach programs, libraries and data), and install in
this workdir the missing built dependencies.

This is where unionfs, as unprivileged (manipulating the namespace)
shows all its potential (Plan9 has gone quite a way in this direction
and the solutions are elegant; but they do not fit nicely with Unix,
this requires more in depth modifications).
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C