root password

[Albert Cahalan]

On Jan 3, 2008 12:15 AM, Bernardo Innocenti <bernie at codewiz.org> wrote:
> Albert Cahalan wrote:

> > auth      required    pam_succeed_if.so use_uid user ingroup wheel
...
> This seems really equivalent to using pam_wheel.so.

I thought so to, but testing seems to show that pam_wheel.so
will only protect transitions to the root account. It does not
protect olpc, at least not without some undocumented option.

> > This is an excellent idea. Doing tty1 through tty6 would
> > be good.
>
> Using just 2 shells was a way to save some memory.  Kids will
> use none.  Whoever needs more can easily edit /etc/inittab.

Shall I write you a tty-watcher program in assembly code?

This really shouldn't cost much memory. Even with glibc,
I doubt the dirty memory was all that much.

BTW, I'm serious about the assembly code.

> Moreover, I strongly feel that /sbin and /usr/sbin are the
> creation of the devil and serve no other purpose than irritating
> unprivileged users when they want to call ifconfig or mount.
> It also interacts especially badly with "sudo -s" and "su".
>
> Therefore, I've just added /usr/local/sbin:/usr/sbin:/sbin to
> the user path.

That makes tab completion less useful for non-root users.
It's nice to get more letters when you hit tab, and to get a
smaller list of possible completions when you hit tab a
second time.

> > Note that the above does not require sudo to work. It doesn't
> > even require su to work, given that sudo doesn't work.
>
> Good point, but if we left just that in place, we'd have to
> ask people to use the ugly text console more often, where the
> keyboard works partially and there's no cut & paste.

It's not ugly if you ship the nice 15x30 font I made.

Cut-and-paste can be fixed, with the difficulty depending
on how perfect you want it. One can run gpm. This can
be started when a user logs in on the console. One could
even write something to feed that into the X clipboard and
back.

> > I don't believe there is any real need to protect the root
> > account from the olpc account.
>
> There is: the Browse activity still runs as olpc because it
> is hard to containerize.  But one could argue that there's
> not that much of a difference between compromising olpc and
> compromising root on a single-user machine.

That's exactly what I'm thinking: all the interesting
data is in the olpc account.

> > If there is, then a root login
> > should require the SAK key. (Alt-Ctrl-SysRq by default)
> > This is the only way to be sure that one is not typing into
> > a trojan. Maybe Fn-Esc makes a good SAK key.
>
> I wonder how it plays with setxkbmap and loadkeys.

It's intended to work, and I believe it can even kill X,
but I haven't tested it.