zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/24/89)
One thing that bothers me about news (cnews or 2.11) is that it doesn't have any protection once someone breaks the news id - if you break news, you can break many others ids (via a trojan horse) because so many people run things owned by news. Given than news isn't such a hard one to break (cnews took me about 10 min - it's being fixed) this is a problem. I'd much prefer that everything went through a root owned program that did a setuid(),setgid() to news before doing anything. Uucp has the same problem. If you can break it, you can break many id's. A "firewall" is needed to contain any damage. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI sharkey!b-tech!zeeff
henry@utzoo.uucp (Henry Spencer) (06/25/89)
In article <9482@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >One thing that bothers me about news (cnews or 2.11) is that it >doesn't have any protection once someone breaks the news id - if you >break news, you can break many others ids (via a trojan horse) because >so many people run things owned by news... Note that in our preferred configuration, the binaries that people would run are not owned by news! News owns only the control files, the articles, and one or two crucial binaries. This is not an accident. It's not perfect, but it does reduce vulnerability. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/25/89)
In article <1989Jun24.204900.24693@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <9482@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>One thing that bothers me about news (cnews or 2.11) is that it >>doesn't have any protection once someone breaks the news id - if you >>break news, you can break many others ids (via a trojan horse) because >>so many people run things owned by news... > >Note that in our preferred configuration, the binaries that people would >run are not owned by news! News owns only the control files, the articles, >and one or two crucial binaries. I disagree. Unless I've done the installation very wrong, users do end up running the crucial binaries newsspool and relaynews. If you are using uucp, users indirectly run newsspool via rnews and relaynews is called from inews. These are news owned programs. -- In my next life - Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI sharkey!b-tech!zeeff
henry@utzoo.uucp (Henry Spencer) (06/26/89)
In article <9490@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >... Unless I've done the installation very wrong, users do >end up running the crucial binaries newsspool and relaynews. If you >are using uucp, users indirectly run newsspool via rnews and relaynews >is called from inews. These are news owned programs. Uh, why would a user ever run rnews? Only other systems do that. As for relaynews via inews, yes, this is the only exception to the rule. And this one is absolutely inescapable -- if users are to be able to post news, they have to be able to run something which has news powers. How would you avoid this? -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/26/89)
>>... Unless I've done the installation very wrong, users do >>end up running the crucial binaries newsspool and relaynews. If you >>are using uucp, users indirectly run newsspool via rnews and relaynews >>is called from inews. These are news owned programs. > >Uh, why would a user ever run rnews? Only other systems do that. Users send mail, mail calls uux, uux can call uucico, uucico calls uuxqt, uuxqt calls rnews. Uucp can cause a similar sequence. Yes, users do run rnews all the time (indirectly) and their id is exposed. >As for relaynews via inews, yes, this is the only exception to the rule. >And this one is absolutely inescapable -- if users are to be able to post >news, they have to be able to run something which has news powers. How >would you avoid this? One weak link in the chain is all it takes. The easy secure way is for rnews (ie, the initial entry point) to be a tiny suid root program (in /usr/bin or something) that does a setuid(NEWS), setgid(NEWS) before execing the real rnews. Same for inews. Then someone can break news and not get any further. All other files and news directories can be news owned and the suid root program is easily verified as being secure. I can only speak for Sys V, but these things seem pretty obvious to me. Using a different id (eg news) does little good if all the users have to completly trust it. Make the change I suggest and all the users have to trust is root. -- Are you making the world a | zeeff@b-tech.ann-arbor.mi.us better place? | Ann Arbor, MI
jmc@PacBell.COM (Jerry Carlin) (06/26/89)
In article <1989Jun25.175214.13599@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Uh, why would a user ever run rnews? Only other systems do that. A user would not, an abuser would! >As for relaynews via inews, yes, this is the only exception to the rule. >And this one is absolutely inescapable -- if users are to be able to post >news, they have to be able to run something which has news powers. How >would you avoid this? You can't avoid it but it can be minimized by running the minimum amount of code setuid, hopefully only on startup/file open time, followed by changing to real user. -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe.
henry@utzoo.uucp (Henry Spencer) (06/28/89)
In article <9493@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >One weak link in the chain is all it takes. The easy secure way is >for rnews (ie, the initial entry point) to be a tiny suid root program >(in /usr/bin or something) that does a setuid(NEWS), setgid(NEWS) >before execing the real rnews... In case you haven't noticed, relaynews does those setuids immediately on startup. It even goes through such a tiny setuid-root program if your system does not support setuid(geteuid()), which is the preferred way of doing this. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (06/28/89)
>>One weak link in the chain is all it takes. The easy secure way is >>for rnews (ie, the initial entry point) to be a tiny suid root program >>(in /usr/bin or something) that does a setuid(NEWS), setgid(NEWS) >>before execing the real rnews... > >In case you haven't noticed, relaynews does those setuids immediately on >startup. I've noticed and my point stands. News owns a program that people will be executing with their id exposed. This is a security problem if anyone ever breaks news. You have recognized and addressed most of this problem by making most things bin owned. My point is that "most" isn't worth much. A suid root "wrapper" at the entry points eliminates the problem (you can even let news own the stuff in /usr/lib/newsbin, which can be convenient if the news maintainer doesn't have root). >It even goes through such a tiny setuid-root program if your >system does not support setuid(geteuid()), which is the preferred way of >doing this. This is the right idea, but it's done too late (a news owned program has already been executed by the user) and it would have been more efficient to just run the setuid root program first on systems that need it (do it at configuration time, not run time). -- Are you making the world | zeeff@b-tech.ann-arbor.mi.us a better place? | Ann Arbor, MI