hutch@net1.ucsd.edu (Jim Hutchison) (11/07/88)
Unix is not a "secure" system. No system attached to a network is
entirely secure. Valid and illicit network transactions can be
identical. A casual shell expansion here, a little flexibility in
input for a mailer there, ... the system not designed to stop intruders
lets them in. For security, put the machine in a red Tempest can and
seal it up tight. Or looked at in another light, more damage could
have been done with a modem and 10 popular women's names!
The type of hole through which a recent Deutschlander climbed, still
exists. The casual hole. A broken piece of software that did not
get updated, or came back from a backup when the controller scrawled
wild accusations across the system partition. Human error is real,
it can not be ignored. Most importantly, it will happen to you.
Locks are for children and honest people. It is nice to know that
there are "locks" on the doors of the system. I don't go out cracking
security, I'm simply not interested. Almost anyone *can* crack
security. BSD security is not particulary more ventilated than SysVr*,
or VMS. Software has bugs. Get it. If it fails to deliver a letter,
or lets in "the man with no name", it's still just a bug.
Hopefully this article has not fed any hysteria.
/* Jim Hutchison UUCP: {dcdwest,ucbvax}!cs!net1!hutch
ARPA: JHutchison@ucsd.edu
These are my opinions, and now you have your perceptions of them. */scott@attcan.UUCP (Scott MacQuarrie) (11/09/88)
There is a product available from AT&T's Federal Systems group called MLS (Multi-Level Security) which provides B1-level security in a System V Release 3.1 environment. I have seen the product on a 3B2, it's availablity from other vendors would probably require work by those vendors. (Yes Henry, we might even help them do that :-) ). Scott MacQuarrie AT&T Canada Inc. uunet!attcan!scott p.s. Opinions are my own.
ron@ron.rutgers.edu (Ron Natalie) (11/10/88)
...and I have worked on IBM's B2 product, but I fail to see what that has to do with the discussion. A bug in either product can cause it to fail to do what it is supposed to do. In the development group the Trusted System Programmer frequently has backdoor functions to bypass the Mandatory Access Control on the test system that one hopes are never installed in the field (this is much akin to the exploited DEBUG bug in the BSD systems). And any secure workstation that's plugged into a network is very suspect. I believe NCSC won't even talk to you if you put an ethernet card in the workstation. -Ron
ncoverby@ndsuvax.UUCP (Glen Overby) (11/14/88)
In article <1727@cadre.dsl.PITTSBURGH.EDU> sean@cadre.dsl.pittsburgh.edu (Sean McLinden) writes: >It is clear from Rick Adams' comments that 'not wanting to tip anyone off' >is no excuse. Even binary-only sites can be protected fairly rapidly if >the appropriate channels are used. This sort of thing has been a pretty big issue lately, so I thought I'd chip in a few comments. If information about bugs (or, should I say, "misfeatures") in Unix (or really any OS) should not be publicly disclosed to protect those who either do not or can not repair them, then HOW should such "classified" information be distributed to those who want/need it, and can and will fix the holes? Not but a few weeks ago there was a "discussion" on one of the news.* groups about the Security mailing list (there are two of them, but thats irrevalent here) which is restricted to "trusted" people (those who are "root" on a "major machine" -- whatever that means). Now, if information about security bugs is too risky for distribution among that elite group of "system gods", then should that information be exchanged over network mail systems at all? (e.g. to 4bsd-bugs@ucbvax). I think all of this sort of information should be distributed at least over the private security forum; Vendor releases just aren't frequent enough to fix these problems in a timely manner. Glen Overby ncoverby@plains.nodak.edu uunet!ndsuvax!ncoverby ncoverby@ndsuvax (Bitnet)
rbj@nav.icst.nbs.gov (Root Boy Jim) (11/18/88)
? From: Rahul Dhesi <dhesi@bsu-cs.uucp>
? Date: 12 Nov 88 20:46:57 GMT
? Keywords: bug reality
? In article <14505@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
? >Actually, you get a `daemon' shell---not as bad, but, as Keith put it,
? >`not my idea of a good time'.
? But at's jobs to be executed are owned by daemon, so isn't being daemon
? just a trivial step away from being root? Somebody mentioned this
? earlier and nobody contradicted him.
? --
? Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
So who uses `at'? Maybe you like batch? On our sun, a daemon user could
tamper with the line printer queues and delete all the log files. Perhaps
worst of all is that /usr/etc/in.syslog is writable by daemon.
I'm sure there are other holes.
(Root Boy) Jim Cottrell (301) 975-5688
<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
Crackers and Works -- Breakfast of Champions!cja@entebbe.eecs.umich.edu (Charles J. Antonelli) (11/18/88)
In article <chomp!> Rahul Dhesi (dhesi@bsu-cs.uucp) writes: > But at's jobs to be executed are owned by daemon, so isn't being daemon > just a trivial step away from being root? Somebody mentioned this > earlier and nobody contradicted him. > -- > Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi consider the statement contradicted. daemon is just another non-root uid. Charles J. Antonelli Internet: cja@crim.eecs.umich.edu 44 ATL, 1101 Beal Ave. Uucp: {uunet,rutgers}!umix!eecs.umich.edu!cja The University of Michigan Phone: 313-936-9362 Ann Arbor, MI 49109-2210 "When the going gets tough, the tough reboot."
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/18/88)
In article <1308@zippy.eecs.umich.edu> cja@crim.eecs.umich.edu (Charles J. Antonelli) writes: >consider the statement contradicted. daemon is just another non-root uid. Not quite right. Several "system" UIDs/GIDs can be exploited to cause a variety of unanticipated actions, some of which can eventually yield superuser access rights. The cron system is an obvious candidate for this since at some point a superuser-privileged process handles the files. Even a system administrator or programmer's account may be enough to sneak a Trojan horse into a system, which can if it wishes wait until invoked by UID 0 to do further mischief.
gandalf@csli.STANFORD.EDU (Juergen Wagner) (11/18/88)
In article <1308@zippy.eecs.umich.edu> cja@crim.eecs.umich.edu (Charles J. Antonelli) writes: >In article <chomp!> Rahul Dhesi (dhesi@bsu-cs.uucp) writes: >> But at's jobs to be executed are owned by daemon, All the "at"s I have tried execute jobs under the user's uid, not as daemon. If that's the case on your system, I think it is a bug, and it should be fixed! -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
dhesi@bsu-cs.UUCP (Rahul Dhesi) (11/19/88)
I rashly said
But at's jobs to be executed are owned by daemon,
and they won't let me hear the end of it.
In article <6491@csli.STANFORD.EDU> wagner@arisia.xerox.com (Juergen Wagner)
writes:
>All the "at"s I have tried execute jobs under the user's uid, not as daemon.
The trouble is that once you are daemon, you can queue an "at" job to
be executed as root.
As for the question "does anybody use at?", the answer is Yes. I use
it to queue postings for comp.binaries.ibm.pc, and others here use it
for things like queuing UNIX <--> VMS file transfers etc. for early
morning hours.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesijfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/19/88)
In article <1308@zippy.eecs.umich.edu> cja@crim.eecs.umich.edu (Charles J. Antonelli) writes: >In article <chomp!> Rahul Dhesi (dhesi@bsu-cs.uucp) writes: >> But at's jobs to be executed are owned by daemon, so isn't being daemon >> just a trivial step away from being root? Somebody mentioned this >> earlier and nobody contradicted him. > >consider the statement contradicted. daemon is just another non-root uid. Rahul may be correct. Various old versions of at(1) were very lax in the security department. Newer at's use the SUID and SGID bits of the file for authentication. It was possible under old at(1) implementations to forge an at-job and become root. The only fix was to turn it off or have it run as some non-privileged user, such as daemon. In which case, you couldn't execute any privileged commands. However, if the work files were stored in a directory which only daemon had write permission in, and this was being used to protect an at-daemon running as root, then being daemon would be one step from root. In short, the problem MAY exist. Other situations might be scripts or crontabs owned by a non-priviledged user, but executed by privileged programs, such as at(1) or cron(1). -- John F. Haugh II +----------Quote of the Week:---------- VoiceNet: (214) 250-3311 Data: -6272 | "Okay, so maybe Berkeley is in north- InterNet: jfh@rpp386.Dallas.TX.US | ern California." -- Henry Spencer UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
haynes@ucscc.UCSC.EDU (99700000) (11/19/88)
In article <4820@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >The trouble is that once you are daemon, you can queue an "at" job to >be executed as root. > As soon as I get a new system (with source) I apply a 2-line patch to atrun.c such that, right before the setuid() call, if the uid is going to be root it exits. A side effect is that it leaves the offending file in /usr/spool/at/past, so you can examine it at your leisure. Not that I've had that many to examine... haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle
mouse@mcgill-vision.UUCP (der Mouse) (12/02/88)
In article <1308@zippy.eecs.umich.edu>, cja@entebbe.eecs.umich.edu (Charles J. Antonelli) writes: > In article <chomp!> Rahul Dhesi (dhesi@bsu-cs.uucp) writes: (Is that really the Message-ID of Rahul's article? I hope not!) >> But at's jobs to be executed are owned by daemon, so isn't being >> daemon just a trivial step away from being root? Somebody mentioned >> this earlier and nobody contradicted him. > consider the statement contradicted. daemon is just another non-root > uid. Not "just" that. On our 4.3, at least, the at queue *is* owned by daemon. Therefore, if I can break in with uid daemon, I can queue an arbitrary at job to be run by an arbitrary user, such as root. Now what was that again about how daemon was just another non-root uid? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu