danl@cbnewsc.ATT.COM (daniel.r.levy) (04/27/89)
Can someone tell me which unix-pc files, under version 3.51 system software, MUST be writeable by others? I checked my system (that's my personal system, at home) and I found a surprising number of files and directories to be writeable by anybody, including some humdingers like /, /usr, /usr/bin, and /usr/lib/ua. Now some of this stuff seems to be connected with preference parameters (like /usr/lib/ua/.blanktime) that need to be alterable from any user's office, and others obviously SHOULD be writeable by others (/tmp, /usr/tmp, /usr/lib/spell/spellhist), but things like / shouldn't be. Tnx... -- Dan'l Levy UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!danl AT&T Bell Laboratories 5555 West Touhy Avenue Any opinions expressed in the message above are Skokie, Illinois 60077 mine, and not necessarily AT&T's.
thad@cup.portal.com (Thad P Floryan) (04/29/89)
Re: Daniel Levy's questions about which directories should be writeable .. the /usr/lib/ua most definitely, so that anyone can do "rm -f /usr/lib/ua/*" :-) :-) :-) :-) :-) :-) :-) Seriously, I strongly suggest you acquire the book UNIX SYSTEM SECURITY, by Patrick Wood and Stephen Kochan, publ. Hayden Books UNIX System Library. If you follow the guidelines outlined in that book, both Ivan and Moammar will be gnashing their teeth in frustration. :-) :-) :-) The default UNIXPC system "security" sucks dead bunnies through a straw. Thad Floryan [thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad]
danl@cbnewsc.ATT.COM (daniel.r.levy) (05/04/89)
In article <17736@cup.portal.com>, thad@cup.portal.com (Thad P Floryan) writes:
< Re: Daniel Levy's questions about which directories should be writeable ..
<
< the /usr/lib/ua most definitely, so that anyone can do "rm -f /usr/lib/ua/*"
[wipe dat smirk offa you face...]
And also so that non-install users can create/delete files in there, on
purpose?
< Seriously, I strongly suggest you acquire the book UNIX SYSTEM SECURITY, by
< Patrick Wood and Stephen Kochan, publ. Hayden Books UNIX System Library.
<
< If you follow the guidelines outlined in that book, both Ivan and Moammar will
< be gnashing their teeth in frustration. :-) :-) :-)
No I'm not concerned about Russian and Arab spies.
< The default UNIXPC system "security" sucks dead bunnies through a straw.
Gee tell me something I don't know. I'm not asking about what's good UNIX
security in general (I presume that Wood and Kochan's book is about that, not
about the 3B1 in particular). I got plenty of training about that at work.
What I want to know is, WHAT WILL BREAK when I try to impose conventional ideas
of UNIX security (please hold the wise cracks) upon a 3B1? And I'd like to
know it before I try it and hose up the machine. Right now, the only one who
has a login on that machine is me so I don't care about the sloppy security
any more than I would on a MS-DOS machine. (Well I do care a little re uucp,
since I poll a machine at my work location, but I've fixed up the USERFILE so
it only allows transfers to/from /usr/spool/uucppublic. As it comes, it
allows transfers to/from ANYWHERE... brrr.) But should I ever want to let
strange users onto this beast, well....
--
Dan'l Levy UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!danl
AT&T Bell Laboratories
5555 West Touhy Avenue Any opinions expressed in the message above are
Skokie, Illinois 60077 mine, and not necessarily AT&T's.mark@umbc3.UMBC.EDU (Mark Sienkiewicz) (05/05/89)
In article <672@cbnewsc.ATT.COM> danl@cbnewsc.ATT.COM (daniel.r.levy) writes: >In article <17736@cup.portal.com>, thad@cup.portal.com (Thad P Floryan) writes: >< the /usr/lib/ua most definitely, so that anyone can do "rm -f /usr/lib/ua/*" > >[wipe dat smirk offa you face...] > No smirk is necessary. The user agent is a huge security hole. >Gee tell me something I don't know. I'm not asking about what's good UNIX >security in general (I presume that Wood and Kochan's book is about that, not >about the 3B1 in particular). I got plenty of training about that at work. >What I want to know is, WHAT WILL BREAK when I try to impose conventional ideas >of UNIX security (please hold the wise cracks) upon a 3B1? And I'd like to To make a secure Unixpc, do this: 1 - Kill the user agent. 2 - do the things that make a normal Unix machine secure (e.g. the stuff in that book). I did this and the machine works perfectly. Some experiments revealed that securing the machine DOES break a number of UA functions, mostly those related to setting up the machine. The only non-UA thing I can remember that got broken was cu. (it uses /usr/bin/setgetty to edit /etc/inittab. If you allow setgetty to work, you allow dialup non-priv users to disable logins on the console.) You can fix this by replacing /usr/bin/get{on|off}.sh with empty files; you just can't dial out if there is a getty on your phone. I found that a good compromise was to 1) lock the machine down real tight [of course, I hated UA]. 2) introduce some new security holes so I don't have to type su very often. [e.g. make /etc/mount setuid to root but make it only executable to a group of trusted users.]
scs@lokkur.UUCP (Steve Simmons) (05/05/89)
In article <672@cbnewsc.ATT.COM> danl@cbnewsc.ATT.COM (daniel.r.levy) writes: >What I want to know is, WHAT WILL BREAK when I try to impose conventional ideas >of UNIX security (please hold the wise cracks) upon a 3B1? And I'd like to >know it before I try it and hose up the machine. Well Dan'l, the short answer is ALMOST NOTHING. I did the appropriate find on my system not just for directories but for *every* writable file. Most of them I found could be cleaned up with no risk. A couple I was fairly sure *had* to remain writable (/tmp, /usr/tmp, uucppublic) because system functioning demanded it. One, /usr/spool/news, has to remain writable due to other stupid reasons. There are a couple of accounting files (utmp, wtmp, a few things in /usr/adm) that need to be writable. Getting right down to the bottom, everything else I made protected except /etc/drvtab /etc/timedsply which I just couldn't figure out. Disclaimer: I did this over a year ago, and am telling you from memory. But it's based on real work, not just my opinions. -- Steve Simmons ...sharkey!lokkur!scs scs@lokkur.dexter.mi.us "Gordon Way's astonishment at suddenly being shot dead was nothing to his astonishment at what happened next." -- Douglas Adams
rjg@sialis.mn.org (Robert J. Granvin) (05/06/89)
>There are a couple of accounting files >(utmp, wtmp, a few things in /usr/adm) that need to be writable. Getting >right down to the bottom, everything else I made protected except > /etc/drvtab > /etc/timedsply You may also want to consider making root (yes, /) to be NOT world writeable. As supplied, / comes world writeable (777), and it's very happy to be a little more secure (755). -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg
gst@gnosys.UUCP (Gary S. Trujillo) (05/08/89)
In article <1399@lokkur.UUCP> scs@lokkur.UUCP (Steve Simmons) writes: > ...There are a couple of accounting files > (utmp, wtmp, a few things in /usr/adm) that need to be writable. -rw-r--r-- 1 root sys 288 May 7 18:12 /etc/utmp -rw-r--r-- 1 root sys 26028 May 7 18:11 /etc/wtmp Hmmm. I've been running with these files having mode 644 for some time with no apparent problem. -- Gary S. Trujillo {linus,bbn,m2c}!spdcc!gnosys!gst Somerville, Massachusetts {icus,ima,stech,wjh12}!gnosys!gst
roger@banzai.UUCP (Roger Florkowski) (05/08/89)
In article <179@gnosys.UUCP> gst@gnosys.UUCP (Gary S. Trujillo) writes: }In article <1399@lokkur.UUCP> scs@lokkur.UUCP (Steve Simmons) writes: }> ...There are a couple of accounting files }> (utmp, wtmp, a few things in /usr/adm) that need to be writable. } } -rw-r--r-- 1 root sys 288 May 7 18:12 /etc/utmp } -rw-r--r-- 1 root sys 26028 May 7 18:11 /etc/wtmp } }Hmmm. I've been running with these files having mode 644 for some time }with no apparent problem. }-- }Gary S. Trujillo {linus,bbn,m2c}!spdcc!gnosys!gst }Somerville, Massachusetts {icus,ima,stech,wjh12}!gnosys!gst /etc/utmp and /etc/wtmp are modified by getty or login (I know uugetty updates them, I'm not sure about /etc/getty). Since getty is run from inittab (and therefor login), it has root permissions until it has set up the user's environment. Therefor, setting /etc/utmp and /etc/wtmp to the above permissions (644) would work just fine. -- Roger Florkowski {uunet!uvm-gen, attmail}!banzai!roger The People's Computer Company `Revolutionary Programming'