Re: itp: static bins / resolving static debian issues
On Sat, 21 Aug 1999, Justin Wells wrote:
>
> 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.
is it possible to change this?
> 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
> >
> >
>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Chris Mazuc
Reply to: