Security testing: need for a security policy, and a security-critical package process

[Gregory Maxwell]

On Mon, Nov 23, 2009 at 6:39 PM, Jesse Keating <jkeating at redhat.com> wrote:
> Sure, I don't disagree, but I think we can take spots list and use it
> for the 'guest account'.  Then you start picking things off the list as
> you move up the stack to 'university computer lab user (is that really
> much different from guest?)', to 'non-admin user', to 'admin user'.

I tend to think of guest as equal to "kiosk" i.e. the user is expected to
be toxic waste incarnate, with no accountability... and that it is acceptable
to substantially limit a guest in a way which wouldn't be so acceptable for
a regular user. For example, the account could be locked down with MLS so that
regardless of how other users have (mis-)configured their home directory
permissions guest can't touch it (or other user's files in /tmp), or strict
ulimits on guests so they can't OOM the system or forkbomb it.

Users that have named accounts can usually be presumed to have some
accountability: they may be clueless but if they do something malicious you
know who they are. They're also less likely to enjoy bizarre limitations on
their abilities.  I think this generally maps well to the capabilities of
a regular user account on a classic multi-user unix system.

I suppose you could go on to define a kind of power-user role which has,
effectively, all the 'safe' parts of root... the idea being that the user
probably has root on the system in any case, so giving the safe bits
(mostly various system level settings like adjusting the time,
user-application add/remove, system updates, etc) makes things easier and
eliminates transitions to the more dangerous admin account.