--pgp-sign-Multipart_Sat_Aug__5_15:40:16_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Sat, 5 Aug 2006 12:06:58 +0200,
Geert Hendrickx wrote:
>=20
> Interesting, however I'm not sure I'd want a daemon running for every
> privileged action ordinary users should be able to run.  lpd is an
> exception here, since there's queueing involved. =20

There's nothing exceptional about lpd here.  The fact that it does
queueing is just an aspect of the particular service it provides.  The
key is that it has to access files, including devices, using different
credentials than the invoking user can be given; and it has to do so
without allowing the user to directly influence any of the parameters or
filenames, etc. it uses to do what it does; and it first has to
authenticate and authorize users to control access to the service it
provides.  (See, for example, the "rs" capabiilty for printcap entries.)


> Another practical example is to allow console users to mount (and perhaps
> newfs) floppies, USB devices, CD's (s/newfs/cdrecord/).  How would you
> solve that on a typical desktop machine? =20

Well I think if you look at the likes of Apple's OS-X and perhaps other
similar desktop GUI implementations you'll find service daemons much
like those I've described.  I'm not advocating anything new here, or
inventing anything new either.  These ideas were invented by others
(even though they seem to me to be quite simple and obvious) and are
already widely adopted and used in production.

E.g. on a Mac you click a button on the user interface and (IIUC) a
daemon unmounts and ejects the CD.  However hopefully only the user
logged in on the main keyboard & display can do that kind of thing -- a
user connecting from a remote site presumably can't eject the CD or
restart the system, etc.  Note that to implement this functionality with
a privileged service daemon does not require any other special
privileges (i.e. group memberships) to be given to the user logged in on
the console.  However of course for services like printing, or whatever,
which might be OK to be used by a remotely connected user, it is easy
enough to add configuration parameters to the service daemon such that
it can also authorize the specified users, and not just provide that
service to the user who's desk/lap the machine is apparently sitting
upon.

Regardless whether the service is implemented by a daemon or just some
kind of setuid wrapper, the trick is to ensure the protocol between the
user and the front-end is abstract enough such that the user neither has
to worry about the specific filenames and command parameters, nor is
even capable of influencing those values directly.  The "button" or
command used to umount and eject the CD must unmount only the local CD
and not any other filesystem -- same with the "burn" button which must
not create a filesystem on anything but the virtual disk file it just
created to contain the new CD image and it must not write that image to
anything but the local CD-RW drive.

While group membership tricks for sys-admin purposes can have their
advantages, they don't come anywhere near providing the fine-grained
control one needs to allow untrusted users (and their agents) to perform
some kinds of tasks.  A compromised user-ID, say that of a user
permitted to make manual system backups, shouldn't be permitted to
arbitrarily read the raw system disk(s).  That user-ID should only be
permitted to make proper backups.  That demands a service provider of
some sort which can only do the pre-configured operations on the pre-set
disk device(s) and write to the pre-determined archive device(s).  Such
compartmentalization helps reduce the amount of privilege escalation a
compromise can affect.  Taking operator group-read permission off the
swap device(s) doesn't really reduce the risk level any.

Perhaps the service provider thingy could be a hundred-miles-of-hanging-
rope tool like sudo, or maybe it's a special daemon that listens for
commands in a custom protocol on a socket (file or port), but either way
I don't think giving privileged group access to users is in any
way/shape/form the right solution.  The groups feature is of course more
useful for internal implementation of yet further compartmentalization,
i.e. avoidance of just running every service daemon as root.

--=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_Sat_Aug__5_15:40:16_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iQA/AwUBRNT0ImJ7XxTCWceFEQLAVQCg3GfsHIOVrbwA8XV+PjiIFD0D3qwAnjxM
/ppWqfOCNFHzqIECMhIxlfaE
=DoQR
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Sat_Aug__5_15:40:16_2006-1--