Subject: Re: secure, limited, privilege escalation (was: What's in my swap)
To: Geert Hendrickx <ghen@NetBSD.org>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 08/04/2006 20:40:27
--pgp-sign-Multipart_Fri_Aug__4_20:40:20_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Thu, 3 Aug 2006 22:30:40 +0200,
Geert Hendrickx wrote:
>=20
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Thu, Aug 03, 2006 at 04:12:41PM -0400, Greg A. Woods wrote:
> > > - we should create separate groups to implement shutdown(8) and backup
> > >   privileges. =20
> >=20
> > That's not so easy as it might seem.
>=20
> Why not?  Currently, /sbin/shutdown is 4550 for root:operator, so only
> users in the operator group can execute it (with elevated privileges).
> It's as easy as chgrp'ing it to another group (say, "shutdown"), and addi=
ng
> users to that group. =20

Yes, for shutdown alone it _can_ be that easy.

As Steve also says a similar thing can be done for manual backups
without having to mess with device privileges, etc., provided that, as I
said in the first place, a setuid-root program is written to carefully
(i.e. with a very carefully controlled set of command-line parameters)
invoke only the appropriate backup program.  A one-size-fits-all program
(i.e. with enough flexibility for everyone) would be very difficult,
perhaps impossible, to get right and keep secure.  Indeed one might just
give in to the whole idea and just use that horrible and insecure hack
called sudo if all one needs is an after-the-fact audit trail.  (If you
really have an issue with doing regular backups securely from a less
privileged account then perhaps something like Amanda or rdiff-backup is
what you really need.)

However keep in mind that there is a fixed limit to the number of groups
a user can belong to at any one time, and so fractionating privileges
into many fine-grained groups for this kind of thing isn't reasonable
except on a very small scale.  I.e. it's not so easy as it might seem to
take this approach to implementing fine-grained privilege controls.

Another approach to solving this kind of problem while sticking with the
current Unix security model is to write privileged service daemons that
can perform various controlled operations.  Those daemons can be made
configurable so that they accept service requests from a limited set of
specified users that can be authenticated and authorized, after which
the daemon will perform the requested service under carefuly controlled
conditions and using carefully designed and pre-configured invocations
of those commands which must be executed by root etc. or have privileged
access to devices and/or other files, etc.  LPR does something like this
already for accessing printer devices, spool directories, etc. with
special privileges.  This leaves no direct path between the user
requesting the service and the invocation of the service-providing
command, and thus hopefully no way for the user to influence it into
doing something it wasn't supposed to do.  For example a shutdown and/or
power management daemon might always authorize the user logged in on the
"console" to shut down and/or put to sleep the laptop she so obviously
has directly in her hands, and then on the user's behalf it would run
the appropriate command using the necessary privileges.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Fri_Aug__4_20:40:20_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: B44TYnSvJPc26aElwyfS5w7nKON1IKyF

iQA/AwUBRNPo9mJ7XxTCWceFEQKLSQCfRqdbU+WhQPOEtNWyDgTHNGwir70AoIay
MuZ0SwT6T8lVuhx/EOR00qeb
=jd2D
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_Aug__4_20:40:20_2006-1--