Re: itp: static bins / resolving static debian issues
On Sat, Aug 21, 1999 at 10:54:35PM -0400, Justin Wells wrote:
>
> Sorry, "exec /bin/bash" will cause you to get logged out if libc is
> broken. The exec will succeed, bash will try and load its dynamic
> libraries, it will fail, and it will exit. Try it.
I did, actually (as I mentioned), using hard links to sash and bash in
a test directory.
WyrmWeyr:~/static-test$ ./sash
Stand-alone shell (version 2.1)
> exec bash
WyrmWeyr:~/static-test$ exit
exit
WyrmWeyr:~/static-test$ sudo chroot . ./sash
Stand-alone shell (version 2.1)
> exec bash
bash: No such file or directory
> -ls -l /
drwxr-xr-x 2 501 100 1024 Aug 22 03:15 .
drwxr-xr-x 2 501 100 1024 Aug 22 03:15 ..
-rwxr-xr-x 2 0 0 447760 Aug 15 19:37 bash
-rwxr-xr-x 2 0 0 279452 Oct 11 19:00 sash
> exit
It seems to work fine for me. Am I missing something?
> So that's not an option. In fact, the ONLY option is to give root
> a static shell.
>
> However many people insist that there be a root user with bash as
> a shell, so to satisfy these people create a toor user with /bin/bash,
> and give it a disabled password. Anyone who wants to use it can enable
> the password (and take responsibility for it), everyone else can
> safely ignore it.
If I did make a mistake above, or the proposal is rejected for other reasons,
then I definitely agree that said account should be disabled.
Another thing: for all you guys who don't want to automatically set root's
shell to something else, would it be a reasonable practical solution
(assuming my other proposal is shot down) to ignore root's shell if set, but
make sash the default root shell on new systems? This would follow the
principle of least surprise, though it might make things pretty hard for
the new users who don't know what they're doing.
> I leave toor disabled on BSD systems since I am content to type "bash"
> or "exec bash" when I have more than 2-3 commands to run as root.
>
> Justin
>
>
> On Sat, Aug 21, 1999 at 05:46:02PM -0700, Nathaniel Smith wrote:
> > 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
> >
Reply to: