> Just re-reading some old-email, I thought I might mention that in the book
> "The Basic Kernel Source Code Secrets" by Jolitz & Jolitz : 1-57398-026-9
> they present another approach.
>
> 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.
>
I worked for DataGeneral for a while, writing security tests for the B2
evaluation of their secure DG/UX. DG/UX B2 uses role based security
extensively and I gained quite an appreciation for the concept. Using this
paradigm, root is just another user, if he exists at all. Stack overflow
attacks are not nearly as dangerous as it vastly reduces the number of
lines of code in privilidged programs which are at risk for granting extra
privilidges. You can set a certain privilidge either on a user or an
executable file and the program must make a system call to assume that
mantle of authority before it executes privilidged statements. It must
then drop the extra privilidges as soon as it's done with them. So instead
of a full program executing with root authority on the system, you've got
3 lines of code whose only extra ability may be to open a port under 1024.
They're working on incorporating Posix 1.e into the Linux kernel -- check
the Linux documentation project pages. I found a link to the group doing
the work there. As soon as it's fairly stable, I'm going to start using
that.
-- ------------------------------------------------Bruce Ide greyfox@greyfox.org http://www.greyfox.org