Subject: Re: $HOSTALIASES thing.
To: None <tech-kern@netbsd.org, tech-security@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 11/03/2000 18:02:36
[ On Friday, November 3, 2000 at 14:29:08 (-0500), Thor Lancelot Simon wrote: ]
> Subject: Re: $HOSTALIASES thing.
>
> On Fri, Nov 03, 2000 at 08:17:24PM +0100, Ignatios Souvatzis wrote:
> > When be talk about "xterm" and its capability to write utmp records:
> > 
> > wouldn't the right solution be to have a special purpose daemon listening
> > on some socket in /var/run, where interested programs can send their log info
> > to, and have things like xterm always run completely unpriviledged?
> 
> That can't work.  You can't run them "completely unprivileged" because you
> can't let everyone write to utmp.

Well, actually it can (well, xterm itself can run "completely
unprivileged" -- obviously something needs to have enough privilege, but
not necessarily super-user privs, to write to utmp, etc.).  I had been
working on this very scheme for a while now.  The daemon also runs
un-privileged, but has write permission to the session accounting files.
The trick is that the daemon doing the writing must authenticate the
information it is about to write.

A somewhat simpler and much more elegant solution is to simply define a
group-ID which is privileged to write to the [u,w]tmp, lastlog, and
similar files; and to give set-group-ID privileges to programs like
xterm which must store session accounting information.  This seriously
compartmentalises any damage that can be done by an exploit while at the
same time keeping the implementation completely trivial and mostly
transparent.

This won't solve the entire problem for xterm though unless pty
allocation can be re-invented to work properly with a "clone"-style
interface where the kernel assures that the new slave device is owned by
the user allocating it.  This change of ownership could also be done by
a privileged (i.e. superuser) daemon too, but the authentication is much
more difficult and the risks are much higher (due to superuser
capabilities of the daemon).

I've given up the daemon-based approach in favour of the simpler and
more secure pty-cloning approach with group-writable accounting files
and am just trying to find time to take advantage of some new
developments in this direction.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>