On Wed, 5 Sep 2001, Greg A. Woods wrote:

> [ On Tuesday, September 4, 2001 at 12:16:15 (-0700), Bill Studenmund wrote: ]
> > Uhm, how about src/etc/etc.i386/ttys revision 1.12, or
> > src/etc/etc.macppc/ttys revision 1.3? I just did a cvs update, and these
> > are the current revisions.
>
> In those revisions of those files all of the _enabled_ "secure" ttys are
> directly and implicitly related to the physical console.
>
> If you're going to try to claim that a disabled or commented out entry
> is an indication of a policy guideline then I think you'd better think
> again!  The point here is that out-of-the-box NetBSD will not actually
> allow the root account to be directly accessed unless the tty is marked
> "secure", and obviously it must also be enabled at the same time too!

No, my point is that the presence or absense of "security" in said file is
not the indicator of canon that you and other folks who are arguing about
"secure" in /etc/ttys are making it out to be.

> > The whole point of this thread is a disagreement about that policy. It did
> > not used to be a written one, but an unwritten one. And it ended up being
> > a different policy for different people.
>
> Yes, of course it's an unwritten policy.  However the way I and others
> have interpreted it though is very VERY much in line with written
> guidelines published by many different computer security experts, and
> indeed is logically in conformance to the very most generic guidelines
> about maintaining good computer security.
>
> You and the other's who've been trying to make a different
> interpretation seem to be making some very non-standard and unstated
> assumptions about the environments you're considering and the

You missed part of that paragraph..

They are non-standard to you. You're trying to argue the majority ground
w/o proving you have it.

Also, the point is that it's quite backwards to argue a change as being in
line with an unwritten, ambiguous policy. Both you and I agree it was/is
unwritten, and the fact we disagree makes it rather clear that it was
ambiguous. :-) To use such an arguement makes for a weak case..

[snip]

You've dived into the world according to Greg, a place most of the rest of
us don't reside. I don't see much point in arguing with you about it, as I
doubt you'll ever change that opinion.

> The idea behind the "secure" flag in /etc/ttys is of course to makes it
> possible to restrict authorised users to only using terminals which
> might be in a secure location where there might be an audit trail kept
> of their access to the location (eg. a sign-in log, or an electronically
> recorded pass card, etc.) when they login as the generic, but supremely
> privileged, "root" user.  If I'm not mistaken the "secure" flag was
> specifially invented in *BSD to deal with the issue of ptys such that
> root logins could implicitly be prevented on ptys which were, even in
> the very beginnings of TCP/IP, known to be flatly insecure when used to
> connect a network circuit to a login session.  Where a secure terminal
> is not used the idea is to force authorised users to first authenticate
> themselves with their own personal unique user identity an then require
> them to use the "su" utility such that an audit trail is left to show
> which real person accessed the generic account in a given session.

You seem to be rehashing two other arguements of this thread. One is about
audit trails, which Curt has said was not a reason for this change. The
other is that the absense of "secure" for ptys implies that network
connections can't be "secure". I think the latter is a great fallacy -
marking ptys as "secure" can open up so many cans of worms that the
absense of "secure" on them means nothing.

Take care,

Bill