Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!edcastle!hwcs!zen!frank From: frank@zen.co.uk (Frank Wales) Newsgroups: comp.sys.hp Subject: Re: HP-UX problems and suggestions (s800) Keywords: HP-UX s800 3.1 Message-ID: <1722@zen.co.uk> Date: 1 Oct 89 18:17:28 GMT References: <1717@zen.co.uk> <1989Sep28.134347.17060@hellgate.utah.edu> <4310060@hpindda.HP.COM> Reply-To: frank@zen.co.uk (Frank Wales) Organization: Zengrange Limited, Leeds, England Lines: 121 [I knew I'd get some things wrong...] In article <1989Sep28.134347.17060@hellgate.utah.edu> mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis) writes: >In article <1717@zen.co.uk> frank@zen.co.uk (Frank Wales) writes: >>1) The information stored in "/etc/disktab" for the 7963 >>disk drive results in newfs(1M) correctly displaying that >>the drive has 304MB of disk space (297108 1K blocks in section 2). >>... >>Yet once the disk has been formatted and mounted, bdf(1) reports only >>278MB available. This leaves almost 10% of the physical disk space >>unavailable > >I'm confused. Are you talking about the standard 10% extra space available >only to system stuff, or another 10% on top of that, i.e., what if you did >newfs -m 1% ... The minfree on most of our larger partitions (except /tmp and /) is typically 2 to 5%; as an experiment when reorganising our partitions for the 3.1 upgrade, I tried various combinations of minfree, fragment and block sizes on one of our 7963 packs, and even with 0% minfree, I couldn't get the available size above 278M. Here is an example line from bdf(1) on such a disk: Filesystem kbytes used avail capacity Mounted on /dev/dsk/c4d0s2 278874 224411 40519 85% /zen Note that the total of the used+avail is 264M, consistent with the 5% minfree I specified at newfs(1M) time. The number I was referring to is the 278874 kbytes. Since then, some mail I have received suggests that HP-UX's default inode allocation may be swallowing the space, and, having had a root around (:-)), this looks likely (we have an awful lot of inodes on that disk, and most seem to be waiting around for something to point to). Now, although I should have thought of this myself (I've been at this sys admin lark a few years now), this is the first time someone from HP suggested looking at the inode count, despite having officially called this in as a problem. At the next opportunity, I'll cut the number of inodes down by a chunk and see what happens. In article <4310060@hpindda.HP.COM> human@hpindda.HP.COM (Aaron Schuman) >Frank> HP-UX is consistently shipped with inappropriate file >Frank> permissions (mostly on executables). >Frank> Specifically, executables are installed with read >Frank> permission enabled. This violates the principle of >Frank> minimum information, and is a potential security problem, >Frank> since unfriendly users can use the strings(1) utility >Frank> to examine the data spaces of executables (or indeed >Frank> the entire files) for clues on how to defeat protection >Frank> mechanisms, for example. > >When we were establishing the defaults, we did consider >the principle of minimum information. We decided leave >executables readable because honest users have legitimate >reasons to read executables (running /usr/bin/what to >determine a version number before reporting a defect, >for instance), and because dishonest users are quite >likely to have access to some Unix-derived source code >anyway. Even if it isn't HP-UX, it's probably similar. Hmmm. Even though I see the point, I find it hard to agree with it. I'd rather make special arragements for programs like what(1) (setgid to bin, and binaries group-readable, say) than ship with loose permissions and expect sysadmins to tighten things up. It makes more sense to me to make it the responsibility of the customer to reduce security rather than increase it, especially as many sys admins I know are too busy or too trusting of the vendor-supplied system to actually go around and change things. (One customer of ours, for which I am developing a comms system, won't even change the GenericSysName login prompt. I am now wondering if all the care I've taken with access control, admin logging and other such things will ever get the chance to be appreciated.) Not every customer has the knowledge or the time to do these things, and, to me, it behooves the vendor to ship the tightest system possible, with documentation explaining how to reduce security and the trade-offs involved. To continue with your example of what(1) for a moment; no-one here can use it to determine program versions except sys admin staff, and no-one has ever complained about this. If someone has a legitimate reason for knowing the revision level of a particular program, I'll be only to happy to tell them. Moreover, executing what(1) on /usr/lib/sendmail here gives me what looks like an HP revision code; I really wanted to know if HP had shipped 5.61 sendmail yet. Having stringsed, then finally emacsed, the executable, if a version number of the form 5.anything is in there, I can't find it. But this is a separate complaint. ;-) [And now today's big gaffe (like a giraffe, but with a shorter neck)...] >Frank> Another example: because of unnecessarily liberal file >Frank> permissions, it is not hard to snoop on mail as it is >Frank> being processed by sendmail(1M). Denying 'other' read / >Frank> search permissions on one directory solves the problem. > >I read about that problem recently in Neil G.'s security mail >list, and wrote to HP's sendmail expert immediately. He said: > >David> The configuration file we ship has always made the >David> default queue file mode 600, plus if you don't set >David> the default file mode at all, the default is also >David> 600 (in previous releases, including 3.1, mode 000). >David> If HP-UX sendmail is making the queue files world >David> readable, it's being system-administrator-configured >David> to do so. David is correct; I now know this is a configurable option, I did not before -- o sole mea culpa :-). Such excuse as I can offer is that I did not prepare our current sendmail.cf file, and it is my avowed intention to one day obtain sufficient knowledge to be able to write new ones with cat. When I'm less busy writing products. Eventually. >I hope that somebody at HP responds to each of your concerns, but even >if some of them are not addressed in replies to this note string, you >can be sure that your ideas are quoted in e-mail sent to the people who >are best able to implement them. Sounds good to me; I look forward to seeing them all in 8.0 (modulo the wrong ones, of course). :-) -- Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank] Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217