On Fri, Aug 04, 2006 at 08:40:27PM -0400, Greg A. Woods wrote:
> At Thu, 3 Aug 2006 22:30:40 +0200,
> Geert Hendrickx wrote:
> > 
> > [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.  
> > > 
> > > That's not so easy as it might seem.
> > 
> > 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 adding
> > users to that group.  
> 
> 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.

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.  

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?  

	Geert