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