nagel@beaver.ics.uci.edu (Mark Nagel) (05/02/89)
This has been brought up before, but some people here have recently
re-asked the question, "Why can't we make certain groups readable only
be certain people?" again. Currently, NNTP has no built-in
authentication system other than host authentication. How difficult
would it be to modify things such that any potential client must run a
local program that connects to the remote NNTP server over a trusted
port? Then, if a connection comes in from a non-trusted port, the
server could just deny read access to *any* group that has such access
restrictions. However, if the connection comes in trusted, then the
uid, etc. information transmitted would be known to be secure.
Clearly, this could be broken by a user with a PC and root access, but
for the intended purposes (local groups with uuid or gid based
restrictions), it should suffice. Has anyone ever done anything like
this? Any thoughts?
Mark Nagel @ UC Irvine, Department of Information and Computer Science
+----------------------------------------+
ARPA: nagel@ics.uci.edu | If you improve something long enough |
UUCP: ucbvax!ucivax!nagel | eventually you will throw it away. |rsalz@bbn.com (Rich Salz) (05/02/89)
In <13084@paris.ics.uci.edu> nagel@beaver.ics.uci.edu (Mark Nagel) writes: > How difficult >would it be to modify things such that any potential client must run a >local program that connects to the remote NNTP server over a trusted >port? As you point out, this could be broken by anyone with a PC and/or root access. Note that there are NNTP clients for several systems -- Symbolics, PC, VMS, Twenex -- that have absolutely no concept of the BSD "trusted port" invention. The other problem with this is that it requires your server to know the UID's of all readers, and that doesn't always make sense. And given the heterogeneity, you can't use things like the Unix UID/GID anyhow. I think one easy way to do this is to add an "SGROUP" command which is like the GROUP command but takes a password. A longer range solution might be, sigh, Kerberos. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
fair@Apple.COM (Erik E. Fair) (05/02/89)
Kerberos looks the most promising to me (mostly because there isn't anything else out there that I can just grab code for). Erik E. Fair apple!fair fair@apple.com
jv@mh.nl (Johan Vromans) (05/03/89)
In article <13084@paris.ics.uci.edu> nagel@beaver.ics.uci.edu (Mark Nagel) writes: > This has been brought up before, but some people here have recently > re-asked the question, "Why can't we make certain groups readable only > be certain people?" again. [Etc...] Having to deal with the same problem, I have hacked nntp 1.5 with the following extensions: - the client sends a "HELO <username>" command upon connection, and uses the result instead of the initial "Ready" message if it's 250 or 251. - the server accepts such a "HELO <username>" command, and can use it to delimit access. Posting access is denied by sending "251" instead of "250" (if I remember well). - the newsgroup name matching algorith has been made more restrictive, such that "group-x" means "group-x" only. Extensions could be made to add full 'rnews'-style newsgroups-lists. Of course, this method depends on the co-operation of the client. Any user who can write his own nntp-access routines can bypass the user-based authorization (not the hostname-based authorization). Currently, if no "HELO" command is sent, default access for the host is allowed. Writing the hostname/username in the nntp logfile gives usefull information about the users who are reading news using nntp. Of course this is a hack. It works for me, but it is not fool-proof not completed. If anyone wants to take these modifications as a start, I'll be glad to send them. Johan -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse Automatisering bv uucp: ..!{mcvax,hp4nl}!mh.nl!jv Doesburgweg 7 phone: +31 1820 62944 2803 PL Gouda - The Netherlands fax: +31 1820 62500
eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) (05/03/89)
In article <13084@paris.ics.uci.edu>, nagel@beaver.ics.uci.edu (Mark Nagel) writes: ... > port? Then, if a connection comes in from a non-trusted port, the > server could just deny read access to *any* group that has such access > restrictions. However, if the connection comes in trusted, then the > uid, etc. information transmitted would be known to be secure. > Clearly, this could be broken by a user with a PC and root access, but > for the intended purposes (local groups with uuid or gid based > restrictions), it should suffice. Has anyone ever done anything like > this? Any thoughts? Changing nntp code to look for privileged ports is not that difficult. I have changed my copy of the 1.5 nntp code to do this things, but not for the reason to disallow anyone reading news, but only to prevent forgery of articles. It was only necessary to change the nntp code to achieve that. My nntp inews now has a root s-bit, and will verify the contents of the "from": and "sender:" header fields, before passing the message on to the nntp server (and the nntp server only accepts "post" or "ihave" from privileged ports, if that feature is enabled). If you want a uid/gid based authentication, you will have to change the news reader too, and if you want to administrate the whole from the site fo the nntp server, you will have to change the nntp protocol also. There are too many different news reader by now, to change them all for that (you name the best news reader ?). If you do not change the nntp protocol, than you have to chance against PC's. If you really want to handle groups that restrictive, don't use nntp, don't even use news, use notes or mailing lists. Handling news restrictive contradicts the usenet etiquette. Toerless Eckert (eckert@immd4.informatik.uni-erlangen.de)
amanda@intercon.UUCP (Amanda Walker) (05/04/89)
In article <JV.89May2143345@mhres.mh.nl>, jv@mh.nl (Johan Vromans) writes: >Of course, this method depends on the co-operation of the client. Any >user who can write his own nntp-access routines can bypass the >user-based authorization (not the hostname-based authorization). >Currently, if no "HELO" command is sent, default access for the host >is allowed. The users don't even have to write a program under most operating systems; how about: telnet hostname 119 200 ... HELO root It does keep people from reading some groups accidentally with rrn, I suppose, but that's about it. I wouldn't consider it a security measure by any means. -- Amanda Walker InterCon Systems Corporation amanda@intercon.UUCP / intercon!amanda@uunet.uu.net
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/04/89)
In article <13084@paris.ics.uci.edu> nagel@beaver.ics.uci.edu (Mark Nagel) writes: >port? Then, if a connection comes in from a non-trusted port, the >server could just deny read access to *any* group that has such access >restrictions. However, if the connection comes in trusted, then the What if the connection is coming from a PC-Clone with the right hardware & software? (namely, *ANY* TCP/IP software and an interface, not necessarily an ether card) Boys and Girls ... the Bezerkeley concept of priviledged ports is merely a Unixism and is not enforced elsewhere. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- By all accounts, Cyprus (or was it Crete?) was covered with trees at one time <- -- Until they discovered Bronze
brian@ucsd.EDU (Brian Kantor) (05/04/89)
I think Phil, Erik, and I are in agreement that any authentication of readers or posters is not possible in NNTP using the current spec. My feeling is that such is just a specific case of the general problem of authentication on networks; something like Kerberos seems to be the right approach and might well be something we should add to a revised NNTP spec. User and time-of-day as well as other access controls aren't really the province of the Network News TRANSPORT Protocol spec, but it's clear that we should have some provision to accomodate them, if only by having some way to pass security transactions around as part of the nntp session. I've being vague intentionally. - Brian
pst@anise.acc.com (Paul Traina) (10/28/89)
nelson@sun.soe.clarkson.edu (Russ Nelson) writes: >Is there anyone out there who's addressing the problem of running a >NNTP client on a machine with no local storage? I have recently completed an authentication scheme for NNTP and have been running it here at ACC for the past month or so. Originally it was designed for reliable statistics gathering, but since it does provide proper authentication across unsecure channels (i.e. ethernet), it gives you the basis of a "login" mechanism. While it is not as foolproof as kerberos, it should pass the current US export restrictions (the DES module is removable) and it is self contained. As soon as I build up a distribution kit and write an easy-to-use authentication client program, I'll be soliciting offers for beta-testers. Once we get all of the quirks out of it (actually it should be quirk free, but I'm a pesimist), I'll pack it off to people I consider "the NNTP gods" for consideration as an official protocol enhancement. I see no need to have a NNRP protocol. All you would need to do is to add a new option to the list command to download your .newsrc file after you have authenticated yourself to the server. You can probably live without the "no local storage" rule -- it is more efficient if you can use the PC's local disks as a "cache" for requesting articles. -- "If Madonna is the material girl, then Kate Bush is the ethereal girl." Disclaimer: The views and opinions expressed in this message do not necessarily represent the views and opinions of IBM or its management.