Re: itp: static bins / resolving static debian issues
We should not have a seperate UID 0 account. Doing so will be bad from a
security standpoint, and gain us nothing.
First, the security: while it may be theoretically possible to put wrappers
around passwd and so on, ensuring that the two accounts are kept in sync is
extremely error prone in the long run. Wrapping passwd will work in the
common case, but it is still additional complexity and no guarentee that
something unusual might break the link. I have enough trouble being paranoid
about my root account; I don't need to remember to be paranoid about a toor
account as well, plus think of the people who don't realize that the account
exists at all. This of course might be an acceptable cost if it gained us
a great deal, but I maintain that it does not.
It is not too difficult, and much less scary from a security standpoint, to
set things up so that when root logs in, if bash is for some reason
unavailable, things fall back on sash. Off the top of my head, here are two
possible ways to implement this:
1) add to sash the ability to parse a ~/.sash_profile on startup. In that
file put the line "exec /bin/bash". If bash is broken, the exec will fail
and leave you in sash (I just tested this, using chroot to simulate
deleting my shared libraries).
Cons: changing root's shell becomes slightly error-prone, in that instead of
messing with /etc/passwd or chsh the end-user now has to mess with
/root/.sash_profile.
2) set up login to, if the exec of the shell fails and UID==0, try to
exec /bin/sash instead (and have sulogin add /bin/sash as one of its
fallback shells (I've just filed a wishlist bug against sysvinit with
a patch for this -- it's a good idea anyway)).
Cons: Security risk if root has a restricted shell (does this actually
happen? sudo is probably a better way to do it), hard-coding a shell
selection into a program like login gives me the willys (willies?).
3) <your implementation here>
Either implementation will work for the standard cases:
- if your getty/login is already running, and bash works, then root will be
automatically logged in to bash rather than sash.
- if su is statically linked, it doesn't matter what root's shell is, just
use su -c /bin/sash.
- if sulogin is statically linked, you can get in in single user mode.
- if you're remote, then ssh -c /bin/sash will _probably_ work (what's this
about it using the shell to execute the command? will my solutions
help in this case?).
Aren't these a better technical solution than creating a new UID 0 account
to keep track of? Are there any flaws in my reasoning?
-- Nathaniel
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
>
>
Reply to: