Re: itp: static bins / resolving static debian issues

[Justin Wells <jread@semiotek.com>]

I think we should consider that the alternate root user should be the
one with bash as a shell. This is primarily because single user mode
doesn't give you a choice about which user's shell it's going to 
drop you into. 

The alternate root user could be used for day to day administration 
and could have a dynamically linked shell.

This has an additional advantage:
  
   -- you can default the bash user's password to '*' (password disabled) 
      and an administrator who wants to long in and use bash can then 
      use passwd to set this to something else

Now you don't have to worry about cloning the root user's password. 

The further we go with this discussion, the more arguments arise that 
seem to push us toward the same solution already adopted by several 
other Unixes, which have a bash UID 0 as "toor". 

I guess they already had this discussion, and thought about the same
issues we are now dealing with.

Justin



On Sat, Aug 21, 1999 at 05:38:17PM +0200, Marek Habersack wrote:
> * Steve Willer said:
> 
> > > > set the priority of sash to standard or important. On install, ask if
> > > > you want to make this the default root shell. Default to "yes". Say
> > >
> > > No. It should be installed as a part of the standard installation process
> > > and used as the alternative sashroot account shell.
> > 
> > As long as it asks. If sash asks the question at installation, then a
> > sysadmin who hasn't heard of sash before is now hearing about it. If you
> > silently add a new user, the sysadmin might not notice about the new
> > account or the existence of sash, and surprises are generally bad.
> Agreed. sash installation should be as informative as possible. One should
> be asked whether to:
> 
> 1. create an alternative root account (defaults to Y)
> 2. set the alternative account's shell to sash (defaults to Y)
> 3. if user answers N to 1), then sash should suggest itself as the shell
>    for the root account (defaults to N).
>  
> > You might even consider also asking "What should the sash user be called?"
> > if the user says [Y] to the first question, to give maximum flexibility to
> > the user. If I was installing a machine that sits on the Internet for
> > example, I would probably want to use a non-default username for this
> > non-root user just because it's one less piece of information that a black
> > hat can infer.
> No. It shouldn't ask for the new name. It would be really bad for several
> reasons:
> 
> 1. all the (possible) scripts in standard Debian that rely on the existence
>    of such account would be confused and rendered virtually useless - they
>    wouldn't know what is the new account called. They could ask, but that's
>    at least a bit uncomfortable and not very elegant, not to mention it's
>    error prone and disables the possibility of unattended script runs.
> 2. In case of a user asking for help, how would you tell him to use the
>    alternative UID 0 account? He might've even forgotten what he called the
>    account...
> 
> Besides, why having a well-known privileged account would make the machine
> more vulnerable? root account is well know, is privileged - and for those
> reasons it is protected with special care. That same protection can be
> applied to the new account, AFAICS with no additional effort on the admin
> part - the protection system applied to the root account is based on the
> UID, not the name. And both accounts have UID 0. Also... did you hear about
> the Linux PPC challenge? They published the root account on the
> crack.linuxppc.org machine - and nobody has broken in yet...
> 
> marek
> 
>