operator acct in lunar - WAS: Re:rcs not linning :(

[elaine]

I would propose the following.


a variable ($LUSER? ;-)) holds the UID/GID of the user/group which has
admin, but not root priveliege for (e.g) the following.

build in /usr/src
manage souce and binary tarball caches
adjust system configs (e.g. ldconfig)


Additionally I would like to plan that this (these) variable(s) will
be able to hold authorization info for other security models.

for instance on SElinux: (grsec's MAC will be similar)

all processes (and therefor logins) have an associated 'context' consisting 
of ID, Role, Type.

These are completely orthogonal to unix UID. Role and Type may change
(and for the purposes of system administration may be compared to 'su')

ID, however is completely imutable, improving the trust in audit logs.

Thus when I login as a regular user, I may su to gain root (Unix checks 
are still in force so I need UID 0 for instance to bind a low-number 
network port). and change role to a privileged role, however the daemon-start
will prompt for the password associated iwth my original login. 

Thus I would like to plan on being able to hold this data (for SEL all
that is needed is 'role')


For normal Linux or SElinux we can then think about things like the 
following:

set group-ownership of /var/spool/lunar to GID lunar (or similar)

move ld.so.conf, ld.so.cache to /etc/ld/ and set appropriate GID
privileges to allow the admin group to run ldconfig (with -c -C
options) witouth requiring write privs on directory /etc.

In SELinux we can exercise more control. So by setting the type attributes
of these same directories we can also disallow the root ID/ and sysadm_r
role from these functions. Again I believe that GRSEC can provide 
similar improvements in the granularity of control.

While there are distinct barriers to fully dropping privelege within
Unix authenticiation, with either grsec or SEL it won't require too 
much effort allow nearly all software installations to performed 
start to finish without ever acquiring UID 0.

elaine



On Fri, 19 Sep 2003 22:51:14 +0200 (unchecked - local sync NTPstrat4)
Auke Kok <sofar at lunar-linux.org> did inscribe thusly:

> On Fri, 2003-09-19 at 21:28, Terry Chan wrote:
> > rcs BUILD script now uses "operator" instead of "bin" uid, so rcs is working
> > again.
> > 
> > Terry Chan
> 
> perhaps we should standardize usage of this acct for more occasions
> where privilidges are being dropped? There's plenty of occasions where
> this would come in handy...
> 
> sofar
> 
> -- 
> Auke Kok <sofar at lunar-linux.org>
> 
> _______________________________________________
> lunar-dev mailing list
> lunar-dev at lunar-linux.org
> http://dbguin.lunar-linux.org/mailman/listinfo/lunar-dev