Subject: Re: sshd Change: PermitRootLogin = no (wandering off topic)
To: NetBSD Security Technical Discussion List <tech-security@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-security
Date: 09/06/2001 03:23:21
[ On Wednesday, September 5, 2001 at 23:09:33 (-0400), Steven M. Bellovin wrote: ]
> Subject: Re: sshd Change: PermitRootLogin = no 
>
> In fact, I tend to disagree.  While your points (deleted for the sake 
> of brevity) are, in general valid, you tend to end up with a "polyhost"
> that's not operationally realistic.  People compensate for that with a 
> variety of hacks (often involving sudo) that tend to promote the 
> illusion of more security, but not the reality.  And the reason for 
> that is that "privileged", non-root access to a machine is often 
> equivalent to root, but via a few extra, trivial steps.  

I understand what you're getting at.  However I would claim those kinds
of hacks (eg sudo) really are not necessary for that purpose -- they're
just convenient and they're unfortunately all that a vast number of
people tend to recommend these days.

(sudo in particular isn't really secure in any way that people usually
desire it to be and it's often used in situations where the person being
given what is hoped to be limited privileged access is not strictly
trusted.  I often compare sudo to a poor-man's Kerberos root instance.)

> We are not trying to administer single machines today.  Rather, we are
> dealing with "polyhosts" -- groups of machines (perhaps large groups
> of machines) under common administrative control.  [[...]] Put another
> way, we're administering machines with TCP/IP backplanes.

Yes indeed!  (though not 100% of the time, of course!)  In fact I
alluded to this very issue in an earlier reply to this thread when I
mentioned that I do allow root access via SSH to sub-ordinate machines
from any root session on one carefully controlled administrative server.
In fact in at least one production environment at a small ISP (and maybe
soon two, plus my home network) I'm running a parallel private
administrative LAN between all the servers.  I've put all syslog, snmp,
ntp, dns, icp, amanda, dhcp, etc., traffic on that LAN, and at the
moment I even allow rsh, rlogin, ftp, and telnet on it too, though
that's mostly because no untrusted user is ever even supposed to have
any form of shell access.  My assumption is of course that only highly
trusted people have any kind of access to that LAN (though that's
strictly not true as it's trunked down to a second office on a VLAN
along with public traffic in another VLAN, and the switch it splits out
on again, and the segments out from that switch, are not 100% physically
secure, nor are the switch security features enabled at this time).

However this is, obviously, a customised configuration.  I don't think
it's safe or fair to put this kind of assumption into the default NetBSD
out-of-the-box configuration and hope that every NetBSD system manager
will have the foresight to set up such a more secured administrative
server and to restrict direct root logins on their server farms to this
one (or several) top-level servers.  I think the default policy of
strongly recommending always using 'su' and only ever logging in
directly as root on the physical console, is still the best default
configuration to ship with NetBSD.

What would be good to supply out-of-the-box with NetBSD would be
guidelines, documentation, procedures, and tools to assist designers of
such clusters of hosts.  SSH and various other SSL-wrapped servers are
just some of the components necessary....

>  (I used to say "with long, thin, yellow backplanes", which will show you 
> how long I've been muttering about about this.)

I seem to remember hearing (or reading) you say that phrase, though no
doubt long past the time when the yellow cable ruled the LAN....  :-)
(I didn't really get involved in networked computing until rather
recently -- about 1992 at the earliest, IIRC.)

> What is the right way to do audit trails, in today's environment?  I 
> don't have a complete answer, but I strongly suspect that to do it 
> right, we need a much stronger notion of "session" than we have today.  
> You can find some very old thoughts of mine on the subject in a 1988 
> Usenix paper (http://www.research.att.com/~smb/papers/sessext.ps).  It 
> would be interesting to redo that design in modern terms, since a lot 
> of the problems it tries to address are still with us.

About once a year or so (and especially when issues like this crop up) I
look back at that paper of yours....  Once upon a time I had hoped some
of your ideas from that paper would have made it into SysVr4's TLI
listener and ttymon, but alas they didn't seem to and now in SunOS-5
even the stuff that was there has been mostly broken and/or forgotten.
Back in the late 1980's and early 1990's I was a big user of SysVr3.2
and layers based terminals (DMDs and 705's) both at client sites and of
course for my home system, and many of the issues you discussed in that
paper were common issues for me back then too (especially when I was
considering charging for system usage via dial-up shell access!).
Before SSH came along I also secretly hoped inetd would be obliterated
and replaced by something much more managable!  :-)

One thing I've not yet 100% straightened out in my mind is how to deal
with audit trails where the primary focus is not on resource utilisation
(though with DoS attacks that's still always a lingering issue), but
rather on keeping pure access and activity trails so that any change to
any object in the system, or any access to any object, can always be
tracked back to a person, place, and time.  So much of my early life as
a systems manager was spent dealing with resource allocation and usage
accounting so that I could ensure each user got a fair shair of the
system and so that they would be fingered for abuses and not be able to
put blame on other users for any abuses.  Most of the time I left
privacy and integrity issues up to the users themselves (after of course
teaching them the basics of chmod!).  These days when almost everyone
has very inexpensive resources to throw around, and personal
workstations that can be screwed up without adversely affecting every
other user on the "system", the resource allocation and usage accounting
issues have almost disappeared (I don't personally know anyone in the
coroporate world who doesn't just buy more disk/ram/cpu when they need
it, no questions asked).  Even I don't care too much about such things,
and capacity planning is simply a matter now of measuring job loads and
such and planning for upgrades and fine tuning as necessary.

These days I think I see audit trails and auditing as far more important
than mandatory access controls.  Indeed I'm now also less concerned
about processes and activities than I am about data object access and
change.  In other words I don't know for sure that "sessions" are quite
as important as simply relating initial identity to an authenticated
external entity and then tracking any identity changes (eg. su) in child
process trees, and more or less ignoring what "session" or tty the
processes are attached to (especially if they're just attached to a
pseudo-tty).  With the likes of SSH for initiating remote job execution,
the association of an authenticated real-life person with a process is
more or less solvable and with a good auditing system to track what data
objects that process access and chagnes the activities of a user can be
more or less tracked.  The idea I was working towards was the use of
audit analysis to enforce security instead of requiring users deal
directly with complex technical controls.  I.e. much the same way
real-world non-military security often works.

Coincidentally about the time I was first formulating these ideas in my
mind a very interesting paper appeared in the "New Security Paradigm
Workshop" proceedings, from Sept 1999 [which even though it was held
only a few tens of miles from where I live, I was unable to attend :-(].
The paper is titled "Optimistic Security: A New Access Control
Paradigm", by Dean Povey <povey@dstc.edu.au>.  I had been thinking about
this using the phrase "just-in-time" security, but perhaps one of the
best illustrations of this new paradigm is given by his section title
"Emergency ``break glass'' tools".  To me the image I formed from this
one phrase cemented the ideas in my mind for dealing with policy
enforcment with a much less "military" all-or-nothing approach that
computer users have more or less been forced to use ever since computers
began to support multi-user activity.  Kerberos root instances, and even
some styles of 'sudo' usage, suddenly become a lot more appealing to me.

The tricky part with computers and electronic data is that the recording
of audit trails requires much greater care than it usually does in the
real world since the ability of even a highly experienced forensics team
to reveal integrity problems with the audit records themselves is very
limited.

Confidentiality and privacy issues probably cannot really be handled
with "just-in-time" security though, especially since data can easily be
copied and transmitted through well hidden covert channels, so access
controls cannot be completely dispensed with....

-- 
							Greg A. Woods

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