chris@hypnos.calpoly.edu (The Squire, Phish) (04/26/91)
I seem to recall a variable in news called FASCIST which enabled the "authorized" file. After installing the latest C news, I can't find it. I've disabled Pnews in the meantime, but the users are clammoring to at least be able to post locally. But, with an expected userbase nearing 8000 (2500 now), I can't have posting completely on. We're going to require a form first. In any case, the reason for my rambling is to ask am I missing something, or is FASCIST/authorized just not used anymore? If so, anyone have any ideas? I've written my own parser for authorized, but it can't hurt to ask... -- ++Christopher(Squire_Phish); | cambler@polyslo.calpoly.edu (UNIX) ------------------------------------| chris@hypnos.calpoly.edu (AIX) Relax... I'm not really like that. | chris@erotica.fubarsys.com (HOME) Except when I am. | fsuucp-request@polyslo.calpoly.edu (LIST)
henry@zoo.toronto.edu (Henry Spencer) (04/26/91)
In article <1991Apr26.070028.705000@zeus.calpoly.edu> chris@hypnos.calpoly.edu (The Squire, Phish) writes: >I seem to recall a variable in news called FASCIST which enabled the >"authorized" file. After installing the latest C news, I can't find >it... We've never done this in C News. It's too easy to bypass it; the security is very superficial. FASCIST is a B-News-ism. Given that inews is a shell file, in principle it can be changed to attempt to enforce any rules you want. Inews is, unfortunately, fairly complicated, so this is easier said than done, but it is possible. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
geoff@world.std.com (Geoff Collyer) (04/26/91)
chris@hypnos.calpoly.edu: >I seem to recall a variable in news called FASCIST which enabled the >"authorized" file. After installing the latest C news, I can't find it. >... is FASCIST/authorized just not used anymore? FASCIST is a B News configuration option. I didn't put anything equivalent into C inews because of the fundamental ease of bypassing inews (and any restrictions it imposes) and because FASCIST seemed like a frill in an already-overloaded program. (I should point out that it's easy to bypass inews in B News too; this really is fundamental.) >If so, anyone have any ideas? If you really think no one is going to go to the trouble of bypassing inews, it shouldn't be hard to modify inews and friends to add arbitrary restrictions. -- Geoff Collyer world.std.com!geoff, uunet.uu.net!geoff
pjg@acsu.buffalo.edu (Paul Graham) (04/27/91)
henry@zoo.toronto.edu (Henry Spencer) writes: | |We've never done this in C News. It's too easy to bypass it; the security |is very superficial. FASCIST is a B-News-ism. nntp sites that run authorization can make bypassing inews a bit challenging. some of those sites would like to use C news, if only it had a clean method of posting restriction. -- pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet) opinions found above are mine unless marked otherwise.
peter@taronga.hackercorp.com (Peter da Silva) (04/27/91)
henry@zoo.toronto.edu (Henry Spencer) writes: > We've never done this in C News. It's too easy to bypass it; the security > is very superficial. FASCIST is a B-News-ism. Comment: if you have users with no shell access FASCIST and PRUDE work quite well. News makes a hell of a BBS message system. -- (peter@taronga.hackercorp.com) `-_-' 'U`
billd@fps.com (Bill Davidson) (04/28/91)
In article <1991Apr26.070028.705000@zeus.calpoly.edu> chris@hypnos.calpoly.edu (The Squire, Phish) writes: >I seem to recall a variable in news called FASCIST which enabled the >"authorized" file. After installing the latest C news, I can't find >it. That's because it's a Bnews feature. >I've disabled Pnews in the meantime, but the users are clammoring >to at least be able to post locally. But, with an expected userbase >nearing 8000 (2500 now), I can't have posting completely on. We're going >to require a form first. In any case, the reason for my rambling is >to ask am I missing something, or is FASCIST/authorized just not used >anymore? I use it here to keep people from posting from "anonymous" accounts like "guest" etc. I used to just tell people not to do it but that didn't work. While it's pretty easy for someone who really wants to get around it to do so, most of my users are not that motivated to learn about how news works. They usually have done it from the wrong account by mistake anyway. For me "FASCIST" is more of a convenience feature than a real security measure. --Bill Davidson -- The great thing about Alzheimer's that is you meet new people every day.
chap@art-sy.detroit.mi.us (j chapman flack) (04/30/91)
In article <1991Apr26.152345.26748@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > >We've never done this in C News. It's too easy to bypass it; the security >is very superficial. FASCIST is a B-News-ism. > >Given that inews is a shell file, in principle it can be changed to attempt >to enforce any rules you want. Inews is, unfortunately, fairly complicated, >so this is easier said than done, but it is possible. ...And given that inews is a shell file, any of your users can write a new one to enforce any rules s/he wants and invoke relaynews directly! I've worked around that (on SCO SV3.2 w/ MMDF) by changing the permission on relaynews so it's only executable by news. inews (which is big and slow anyway) checks at an early stage to see if the current user could exec relaynews. If not, inews just `submit's the proto-article as is to an MMDF alias which is a pipe to (you guessed it) inews again, invoked as the news user. This inews completes the article munging (the big slow stuff), enforces any local policy *reliably*, and kicks off relaynews, all while the user goes about his/her other business. MMDF `submit' requires the article to have either a From: or Sender: that doesn't lie, taking care of your authentication, and supplies a message-ID, so anne.jones doesn't have to do that either. None of this *requires* changes to anne.jones since she only adds headers that aren't already there. (Good design, Henry!) This approach also eliminates the need for the suid-ROOT(!!!) `setnewsids'. To prevent all spoofing, however, it's still necessary to ensure that the user can't cobble up a fully formatted article and `uux neighbor!rnews' directly. If your users can't access uux that's not a problem. Otherwise, something needs to be added. I think the most elegant solution is for my neighbor's `rnews' to look in its environment for UU_MACHINE and UU_USER, which are set from values placed (unspoofably) in the X file by uux itself, which had to be setuid to write them. My neighbor should be able to write a little configuration file that says "all legitimate news from art-sy will have been sent by user news; if UU_MACHINE is art-sy but UU_USER !is news, reject the article/batch (or pass it through with a disclaimer) and so forth for his other neighbors. (For that matter, his `rmail' should know that all legitimate mail from art-sy comes from user mmdf.) I think that would be a useful feature to add to rnews. As it is, I use the following ghastly workaround: uucico can be invoked ONLY by cron, which always, before starting uucico, fires up a script that examines all outgoing proto-X-files and puts the kibosh on any rnews or rmail attempts from the wrong users. This would break down if my neighbor polled me instead, and would probably also fail if a user invoked uux during a uucico session. (I suppose I could binary-patch uux to create the spool files in a different directory, and have my cron script move the good ones over. Talk about ugly!) Do news-transport mechanisms other than uucp provide comparable methods for the receiving system to identify the user on the sending system responsible for ultimately causing the transmission? -- Chap Flack Their tanks will rust. Our songs will last. chap@art-sy.detroit.mi.us -Mikos Theodorakis Nothing I say represents Appropriate Roles for Technology unless I say it does.
nigelm@ohm.york.ac.uk (Nigel Metheringham) (05/01/91)
[Reposted, because the idiot who set up nn set the default
distribution to campus - shame that me and that idiot share a
brain!]
I haven't looked at this very hard yet, but think it may be a
reasonable way of getting fascism in C-News. If not I'm sure
someone will point out the problems fast enough.
Basic premises:-
+ Posting is done with inews.
+ Inews calls relaynews after mangling the headers.
+ relaynews is also called by the incoming batch processors
(from a cron job running UID news).
+ relaynews currently runs setuid news to allow it to write the
news articles themselves.
+ relaynews can be called directly, bypassing anything you put
into inews, making inews a bad place to do this...
+ relaynews only needs to be setuid for local posting - ie
anything going through inews - everything else calls it
with the correct uid.
So, why can't we knock the setuid bits off relaynews, and then add a
small setuid (news) program (maybe called injectnews), which is the
one called by inews.
relaynews would still work for processing batches etc, but could not
be called by normal users to bypass the protections...
injectnews checks the current UID against a stop list (or for the
really fascist, against a valid posters list). If it accepted
someone then it could be passed on to relaynews (which would be run
from injectnews, and inherit the setuid status), otherwise it could
drop the article or maybe the distribution header could be
rewritten. For my own use, it would need to look at and possibly
limit the distribution header.
Since posting new news tends not to be the most common operation of
the news system this should not hit performance badly.
So, comments please, before I get my trusty C compiler out....
(Actually it sounds like a job for Perl to me...)
Nigel.
--
# Nigel Metheringham # EMail: nigelm@ohm.york.ac.uk #
# System Administrator # Phone: +44 904 432374 #
# Department of Electronics # Fax: +44 904 432335 #
# University of York, Heslington, York, UK, YO1 5DD #henry@zoo.toronto.edu (Henry Spencer) (05/01/91)
In article <9104300922.aa02031@art-sy.detroit.mi.us> chap@art-sy.detroit.mi.us (j chapman flack) writes: >... None of this *requires* >changes to anne.jones since she only adds headers that aren't already there. >(Good design, Henry!) Actually Geoff gets most of the credit for that, although there has been some evolution since his original design. >... I think the most elegant solution is for my >neighbor's `rnews' to look in its environment for UU_MACHINE and UU_USER, >which are set from values placed (unspoofably) in the X file by uux itself, >which had to be setuid to write them... Alas, those variables are not supplied by older uucp implementations. It's also a little awkward to pass them along through the spooling machinery to the place (relaynews) where they could be understood and checked, although that could be solved in one way or another. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (05/02/91)
In article <1991May1.124919.8706@ohm.york.ac.uk> nigelm@ohm.york.ac.uk (Nigel Metheringham) writes: >So, why can't we knock the setuid bits off relaynews, and then add a >small setuid (news) program (maybe called injectnews), which is the >one called by inews... >injectnews checks the current UID against a stop list (or for the >really fascist, against a valid posters list). If it accepted >someone then it could be passed on to relaynews... It's a viable approach. However, you need to be careful to guard against several other back doors. For example, on a system named (say) utzoo, it is quite possible to do cat myarticle | uux - utzoo!rnews and have the article processed as if it came in from outside. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
kre@cs.mu.oz.au (Robert Elz) (05/02/91)
henry@zoo.toronto.edu (Henry Spencer) writes: >However, you need to be careful to guard against >several other back doors. For what most people seem to want FASCIST for (never used it myself) I doubt that that matters - anyone able to get around it, and actually willing to go to the trouble, probably isn't who you really want to stop (stopping the real bastards is better done with vipw (or similar)). Rather, the idea is to deflect the noise from the newcomers, who accidentally type 'f', then various combinations of 'ZZ' ':wq' ... in an attempt to escape from what they've done, and then post the result. Its not easy to detect this automatically (by looking at the contents of the article), but if you're able to simply prevent postings from anyone who hasn't convinced you that they know how to use an editor, etc, then you'll be a long way towards keeping you local part of uesnet clean. Anyone able to "cat file | uux - utzoo!rnews" obviously knows what they're doing enough to be able to post news (and clearly isn't just making an innocent typo). kre
ross@watcsc.uwaterloo.ca (Ross Ridge) (05/07/91)
In article <1991May1.124919.8706@ohm.york.ac.uk> nigelm@ohm.york.ac.uk (Nigel Metheringham) writes: >So, why can't we knock the setuid bits off relaynews, and then add a >small setuid (news) program (maybe called injectnews), which is the >one called by inews... >injectnews checks the current UID against a stop list (or for the >really fascist, against a valid posters list). If it accepted >someone then it could be passed on to relaynews... On Contact we have programme that does just that (been using since the alpha release of Cnews). We call it censor, as it can accept, reject and hold (for human censorship) news articles by user and newsgroup. henry@zoo.toronto.edu (Henry Spencer) writes: >It's a viable approach. However, you need to be careful to guard against >several other back doors. For example, on a system named (say) utzoo, it >is quite possible to do > cat myarticle | uux - utzoo!rnews >and have the article processed as if it came in from outside. We also have a guard programme for uux. We don't have to worry about NNTP but it's potential back door at other sites. If all fails users can always mail their articles to some-news-group@ucbvax... Ross Ridge