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.
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