On Mar 14,  3:05pm, Greg A. Woods wrote:
> Subject: Re: getpwent(3) funcs return static structure
> [ On Thu, March 13, 1997 at 16:45:18 (+0000), Robert Black wrote: ]
> > Subject: Re: getpwent(3) funcs return static structure
> >
> > Not necessarily. One circumstance under which I think this is very useful
is
> > when you have an outside contactor who needs temporary root access. My
> > inclination would be to create an alternative uid==0 account with a short
> > expiry for the duration of their needing root access, given that they might
do
> > things like writing the root password on a bit of paper in their wallet (or
> > anything else likely to have been drummed out of the heads of normal
employee
> > sysadmins). The temporarily increased risk is far outweighed by the
decreased
> > risk to the *real* root account.
>
> Ah, nope.  ;-)
>
> Either you trust the person you give the root password to, or you don't.
> If uid 0 is compromised, it matters not what the user-id was that the
> compromise was introduced from (unless the compromise was incomplete, in
> which case the hope of an un-compromised audit trail may be of some
> use -- eg. the contractor failed to check where syslog messages are sent
> and didn't prevent the syslog host from receiving the su log entry).

Indeed - you don't give uid==0 accounts to people you don't trust to behave
whilst logged in as that.

> Iff you have some/many people who use the root account regularly (and
> this is a strange high-risk situation in the first place), and you have
> a trusted contractor who needs temporary root access, but you can't just
> change the root password to some temporary value the contractor knows
> because then the others would need to learn it instantly too, then yes,
> creating a temporary uid==0 account with the temporary password for the
> contractor is a definite benefit, and the increased risk may well be of
> minimal importance.
>
> In other words your claim could only be true if the password on the
> "root" account was special in some way.  Maybe it's never changed, or
> perhaps it is shared among many systems.  Iff this is the case then
> having multiple uid==0 accounts is indeed almost risk-free.

You only need contractors to start overlapping and having the password changed
to something the contractor knows starts becoming impractical.

I think the issue here is that NetBSD should not *force* one to have one and
only one uid==0 account. That should be up to the site's security policy which
will vary depending on local conditions. An airwall can make a huge difference
to how one views acceptable risk :-)

Cheers

Rob Black