D. Allen [CGL]) (07/31/90)
Is memory still world-readable under Ultrix 4.0? -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
iglesias@orion.oac.uci.edu (Mike Iglesias) (08/01/90)
In article <1990Jul31.154912.22096@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >Is memory still world-readable under Ultrix 4.0? Nope, /dev/mem and /dev/kmem are only readable by the kmem group. Mike Iglesias University of California, Irvine Internet: iglesias@orion.oac.uci.edu BITNET: iglesias@uci uucp: ...!ucbvax!ucivax!iglesias
avolio@decuac.DEC.COM (Frederick M. Avolio) (08/01/90)
> Does Ultrix 4.0 finally have a secure /dev/*mem ?
Yes. Part of the security subsystem on ULTRIX 4.0.
Fredfrancus@e2big.mko.dec.com (Yoseff Francus) (08/01/90)
In article <1990Jul31.154912.22096@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >Is memory still world-readable under Ultrix 4.0? >-- >-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu > [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada No it is not. /dev/mem now has a 640 protection with ownership of roots and group mem. mem is a new group and has groupid 6. yoseff -- In Xanadu did Kubla Khan A stately pleasure dome decree But only if the NFL To a franchise would agree francus@metsny.mko.dec.com
zemon@ioctl.mko.dec.com (Art Zemon - EIS ULTRIX Unit) (08/01/90)
In article <1990Jul31.154912.22096@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >Is memory still world-readable under Ultrix 4.0? No. /dev/*mem is readable/writable only by root and readable by group "kmem". Appropriate programs are setgid. -- Art Z. by bits: zemon@ioctl.mko.dec.com or ...!decwrl!ioctl.mko!zemon by air: Archer N33565
kinzler@iuvax.cs.indiana.edu (Steve Kinzler) (08/01/90)
Written by idallen@watcgl.waterloo.edu in news:comp.unix.ultrix
---------- "Does Ultrix 4.0 finally have a secure /dev/*mem ?" ----------
> Is memory still world-readable under Ultrix 4.0?
As others have pointed out, Ultrix 4.0 does not have world-readable
/dev/{*mem,drum}, but is group-owned and group-readable by kmem with
appropriate programs setgid kmem.
We achieved the same situation without problem for Ultrix 3.0 by making
these system programs setgid kmem:
######## Mon May 7 17:28:33 EST 1990 ######## kinzler
From: Stephen Kinzler <kinzler>
Subject: Made iuvax memory devices unreadable
Extensively searched the system (iuvax) for files accessing
/dev/{mem,kmem,drum} by doing a grep on the strings of system
executables. I think I caught everything, but it's possible there are
some uninstalled and non-system applications or executables tucked away
in weird places that I missed.
Of the files found ...
These files were already setgid kmem:
/usr/bin/X11/xload /usr/local/etc/ofiles
/usr/local/bin/top /usr/local/lib/emacs/etc/loadst
/usr/local/etc/fstat
These files were made setgid kmem:
/bin/ps /usr/local/adm/bin/gdf /usr/new/mh/msh
/usr/bin/X11/xdm /usr/local/bin/kuser /usr/new/mh/packf
/usr/bin/X11R3/xperfmon /usr/local/etc/batchd /usr/new/mh/repl
/usr/bin/iostat /usr/local/etc/tickadj /usr/new/mh/send
/usr/bin/ipcs /usr/local/etc/xntpd /usr/new/mh/whatnow
/usr/etc/arp /usr/new/dbid /usr/ucb/dbx
/usr/etc/nfsstat /usr/new/lib/mh/rcvpack /usr/ucb/gcore
/usr/etc/pstat /usr/new/lib/mh/slocal /usr/ucb/gprof
/usr/etc/route /usr/new/mh/anno /usr/ucb/netstat
/usr/etc/rwhod /usr/new/mh/comp /usr/ucb/sysline
/usr/etc/savecore /usr/new/mh/dist /usr/ucb/uptime
/usr/etc/trpt /usr/new/mh/forw /usr/ucb/vmstat
/usr/games/rogue /usr/new/mh/inc
These files were also made setgid kmem, even though they're setuid root
since they evidently don't use their root priviledges when accessing
the devices:
/usr/bin/mail /usr/lib/sendmail /usr/local/lib/sendmail
These files were left alone since they should only be run by a superuser
anyway:
/opr/is_vaxstar /usr/field/memx
/usr/adm/bin/sizer /usr/field/shmx
/usr/etc/sizer
This file was left alone since it was already setuid root, setgid uucp:
/usr/local/lib/uucp/acucntrl
After all this, I think we can safely take world-read permissions off of
the memory devices and greatly improve the machine's security, so:
chgrp kmem /dev/{kmem,mem,drum}
chmod o-r /dev/{kmem,mem,drum}
from the brain of Steve Kinzler /o)\ kinzler@iuvax.cs.indiana.edu
an organ with a mind of its own \(o/ {ames,rutgers}!iuvax!kinzlerlidl@eng.umd.edu (Kurt J. Lidl) (08/01/90)
In article <438@e2big.mko.dec.com> francus@e2big.mko.dec.com (Yoseff Francus) writes: >In article <1990Jul31.154912.22096@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >>Is memory still world-readable under Ultrix 4.0? >>-- >>-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu >> [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada > >No it is not. /dev/mem now has a 640 protection with ownership >of roots and group mem. mem is a new group and has groupid 6. > >francus@metsny.mko.dec.com Yes, and therein lies part of the problem. EVERY other BSD-derived system that I have worked on has group kmem as gid 2. In fact, this is one of the "standard" group/gid pairs (kmem/2) that the BSD folks request that everyone have around in the 4.3 (or was it the Tahoe?) release docs. There are a few other groups in there that I wish were standard too... To the best of my knowledge, BSD had the idea for a group kmem first, and as such could make reasonable requests for it. If DEC is going to bother to implement it, why not make it a little closer to the true intent? This implies to me just one more gratuitious change to a supposedly BSD type system. Why? Does DEC enjoy making my life harder? I'm begining to think so... (By the way, the gid of 6 is news on my system -- I thought it was really bloodly funny to find my kernel, ps and other programs setuid to news when I put our "standard" /etc/group file on our first Ultrix 4.0 machine... ) -- /* Kurt J. Lidl (lidl@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!lidl | phrase the question very carefully. */
jv@mh.nl (Johan Vromans) (08/02/90)
In article <52842@iuvax.cs.indiana.edu> kinzler@iuvax.cs.indiana.edu (Steve Kinzler) writes: > We achieved the same situation without problem for Ultrix 3.0 by making > these system programs setgid kmem: > > ... lots of programs ... A number of programs are from MH. Why do these programs need /dev/kmem access? Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62911/62500 ------------------------ "Arms are made for hugging" -------------------------