modla@atux01.ATT.COM (J. Modla) (02/23/88)
The book, 'UNIX System Security', by Wood and Kochan, has a few security programs listed in the appendices. One does security auditing (secure), another checks file permissions (perms), and then there are 2 that do password administration (pwadm and pwexp). Has anyone tried these programs out? I'd be interested to hear about your results. Also, if anyone has one or more of these programs on-line, could you please send me a copy? Thanks a bunch.
dan@coplex.UUCP (05/20/88)
In article <4625@mcdchg.UUCP> you write: >The book, 'UNIX System Security', by Wood and Kochan, has a few security >programs listed in the appendices. One does security auditing (secure), >another checks file permissions (perms), and then there are 2 that do >password administration (pwadm and pwexp). > >Has anyone tried these programs out? I'd be interested to hear about >your results. Hello, We have the book you speak of (a well written one at that) and we have two of the programs you speak of on line. The secure program listed in the back of the book is one that we use from time to time and does a rather good job of it. Assuming you have access to root, it will search for setuid programs that dont belong where they should, globally writable files, stale login ids, etc. It does a good job. A few local modifications and additions are probably going to be necessary to suit your taste however... Of course it isnt necessary though. We also have the pwadm and pwexp programs on line. Seeing that standard system 5 doesn't (for some god awful reason) support any programs (that I know of) that do this for you, it does a good job. All of the time accounting done by /bin/login is handled. You can either read the status of a user or change his status (assuming you have root permissions). You can make him NOT be able to change his password (guest accounts are a good example), FORCE him to change his password upon next login, make him change his password every [n] weeks, etc. This utility works very well if you have a need for cuch things. >Also, if anyone has one or more of these programs on-line, could you please >send me a copy? Thanks a bunch. If you want the sources without having to type them in, just drop a line and I will gladly send you them. As far as the permission program, we didnt implement that one... Sorry. Take it easy, {mit-eddie}!bloom-beacon!coplex!dean
andrew@uel.uel.co.uk (Andrew Josey) (05/20/88)
In article <4625@mcdchg.UUCP>, modla@atux01.ATT.COM (J. Modla) writes: > The book, 'UNIX System Security', by Wood and Kochan, has a few security > programs listed in the appendices. Has anyone tried these programs out? > I'd be interested to hear about your results. > > Also, if anyone has one or more of these programs on-line, could you please > send me a copy? I have been running the programs on a 3B2 running UNIX System V Release 3.1. I quote from the book: "the secure program shown in this book is a very elementary auditing program. It is meant to be a framework..." Secure is a useful starting point and puts many checks into one program that I used to have as a number of scripts. The permissions check program requires you to set up a list of permissions, the ones given are not the most secure, for example: /bin 555 dr-xr-xr-x If you want security why let users cd to or ls /bin, better to set the permissions : /bin 111 d--x--x--x Does anybody out there have a definitive set of "secure" file protection settings for System V (especially Release 3)? I like the pwadmin and pwexp programs, and wonder why this feature has not been provided for in 3B2 sysadm. It's much easier using pwadmin than having to remember "password-ese" ( .=0, /=1, 0-9=2-11, A-Z=12-37...) As for availability of the programs page 3 of the introduction says they are available electronically from Pipeline Associates, Inc. (I have not tried this, and don't know if it works...) I won't give the address here as I'm sure they don't want to be deluged with requests. My overall impression is that the book is worth reading by anyone responsible for system security. No, I am not on commission :-). The programs alone will not secure your system. However, they are a good start and I have added these to my security "toolpack"... -- Andrew Josey, AT&T Unix Europe, a Division of AT&T (UK) Ltd. International House, Ealing Broadway, London W5 5DB, England, UK uucp:{ mcvax!ukc, attunix} uel!andrew { The usual disclaimer .... }
mouse@Larry.McRCIM.McGill.EDU (der Mouse) (06/14/88)
In article <10102@mcdchg.UUCP>, jona@moss.ATT.COM (Jon M. Allingham) writes: > In article <7971@mcdchg.UUCP> usenet@mcdchg.UUCP writes: >> The permissions check program requires you to set up a list of >> permissions, the ones given are not the most secure, for example: >> /bin 555 dr-xr-xr-x >> If you want security why let users cd to or ls /bin, better to set >> the permissions : >> /bin 111 d--x--x--x If you want security you don't want UNIX. If you must have UNIX and you want to come as close as you can, there are many other things to mess with before worrying about users being able to cd to /bin. Tell me, what are you afraid they'll do once they're there? > I would be very annoyed if I couldn't do an ls on /bin (etc.), that > would also mean that programs such as "whereis" (search through your > path to find an executable) wouldn't work either [...] I'd be annoyed too. But, not to defend mode 111 for /bin or anything, a program that runs along your path looking for an executable will work perfectly well if the directories are mode 111. After all, the shell itself does precisely this when you type a command name. (The csh hashes, yes, but that's a detail.) The point is that if you know the name of the file you're looking for, the directory need only permit execute access, regardless of what you want to do with the file itself. > (unless [...] a suid group bin [...]... we don't really need more > suid programs either.) If you want security I don't think you can use the traditional setuid mechanisms. Almost no programs are sufficiently paranoid that they can safely be made setuid, and even in the few cases when the author(s) thought of everything, the available facilities are usually too weak to provide real security. A discussion of access() in some other group (comp.unix.wizards? I think that was it) batted this around and more or less concluded this some time ago.... der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
dtynan@zorba.Tynan.COM (Dermot Tynan) (03/21/89)
In article <10322@mcdchg.UUCP> mouse@Larry.McRCIM.McGill.EDU (der Mouse) writes: >In article <10102@mcdchg.UUCP>, jona@moss.ATT.COM (Jon M. Allingham) writes: >> In article <7971@mcdchg.UUCP> usenet@mcdchg.UUCP writes: >>> The permissions check program requires you to set up a list of >>> permissions, the ones given are not the most secure, for example: >>> /bin 555 dr-xr-xr-x >>> If you want security why let users cd to or ls /bin, better to set >>> the permissions : >>> /bin 111 d--x--x--x Without read permission find wouldn't work. Not to mention some shell utilities which would enable you to type the first few characters of a commend and then complete the commend for you. >If you want security you don't want UNIX. If you must have UNIX and >you want to come as close as you can, there are many other things to >mess with before worrying about users being able to cd to /bin. Tell >me, what are you afraid they'll do once they're there? In the most secure system, information about the existance of certain files is available to the users on a need to know basis. When one succeeds in breaking into an UNIX system, the knowledge of where about of system filex can only help.
dtynan@zorba.Tynan.COM (Dermot Tynan) (03/21/89)
> If you want security you don't want UNIX.
Sorry, Mouse, can't let this pass.
UNIX is *NOT* incompatible with security,
only the standard implementations.
Gould, IBM, and AT&T have UNIXes
(why is it VAXen and not UNIXen?)
that have some degree of certifiable security,
and are working towards higher levels.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have MX records
aglew@xenurus.gould.com - if you don't
uunet!uiucuxc!ccvaxa!aglew - paths may still be the only way
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.