In Appendix B, they describe a method for extending root priviliedges by
replacing the standard suser() check with a more complex (but not very)
function which implements "Role-based security" combined with the notion
of the "access path" which the user is accessing the system from. Hence,
someone logged in from /dev/console can do things like fsck/fdisk/mkfs
whilst the same user logged in on ttyr5 cannot (even though they're root),
but that user can still use ping.
Darren
p.s. where can one get POSIX 1.e ? O:)
In some mail I received from Dave G., sie wrote
> On Thu, 21 Aug 1997, Chris Evans wrote:
> > On Thu, 21 Aug 1997, Jacques Gelinas wrote:
> >
> > > Maybe securelevel bits could be set on executable like a fancy setuid
> > > system. It would be possible to grant a specific privilege to an
> > > executable without giving it full root capabilities (setuid root).
> >
> > This _is_ what POSIX1.e (was POSIX.6) does. It offers seriously good
> > security. I've got my system down to _very_ few suid binaries, most of
> > which could do with inheriting just a single, clearly defined privilege
> > rather than the whole root bundle.
> >
> > egs: ping, traceroute -- open RAW network socket
> > rlogin, et. al -- bind to privileged port <1024
>
> I wrote a small patch that you might find useful. It will allow certain
> groups to open RAW network sockets and bind to privileged ports. It is
> very limited, and POSIX1.e is definitely a better solution, but it is
> available, this is a simple hack.
>
> I have used it to run named, rcp, rsh, rlogin, ssh, traceroute and ping
> without root privileges. I plan on writing better documentation for it in
> the future. So for now you are on your own..
>
> http://www.dec.net/~dhg/patch_prog.html
>
> has that and some other link to toys I have written. A lot of the links
> are broken, because they are works in progress.
>
> Dave G.
> dhg@dec.net