haynes@saturn.ucsc.edu (Jim Haynes - Computer Center) (09/10/88)
This is not a bug report, but rather some ideas/experiences and a plea for others to share experiences. This just seemed like the best place to post it. What I've done so far: 1. Made a directory to hold the stuff from the tahoe tape. Wrote a little 2-line program that does a chroot() to that directory so I can play all I want to without killing the real system. Copied all of /bin, /dev, /etc, /lib, /usr/bin, /usr/ucb from the outside real system into this playground root directory so I would have a working system after doing the chroot(). 2. Bring in the sources from the 4.3-Tahoe tape. Also /usr/include. 3. Discovered later that /usr/include/machine is linked to /usr/include tahoe, so you need to change this before doing anything. 4. Now an open question is what one should do next. Perhaps go to /usr/src/etc/tzone and do a make install there, so that the time zone stuff starts working early in the game? I thought it might be best to remake libc before anything else, so go to /usr/src/lib/libc and do a make and make install. Then seems like it would be good to make the new C compiler, so went to /usr/src/lib and made c2, pcc, and cpp. Wonder if it would be a good idea to change the /usr/src/lib/Makefile so it makes libc first? I guess making /usr/lib should come before making most of the stuff in bin and etc and usr/bin and all that. 5. Being paranoid about security I've been going thru all the makefile and changing modes from 755 to 711 for all the programs except shell scripts. Also changing the owner from bin to root - this is something of a philosophical issue, but I'd rather try to protect root against intrusion than root and bin both. 6. I've had a couple of non-repeatable errors so far, cases where the make reports an error in compilation and stops, but when I re-start it doesn't have the error the second time. This seems highly unusual. Doesn't seem to be a case of flaky hardware, as the underlying real system is working solidly. (The underlying system, in this case, is Mt.Xinu 4.3+NFS). SO - anybody else out there have suggestions to pass along to all of us?
haynes@saturn.ucsc.edu ( Computer Center) (09/10/88)
Since posting the above article I discovered there is a /usr/src/Makefile that takes care of much of doing things in the right order enough times so that you get new libraries and compiler up first. Also noted, however, that you need to make egrep first, because the process of making everything soon invokes egrep with a new -o option that (is not/may not be) available in the system you're using to build. Have had a couple more instances of "compiler error: register allocation error". (while compiling r_tan.c)
chris@mimsy.UUCP (Chris Torek) (09/11/88)
The first thing to do is fix /usr/include/machine; the second
thing to do is to build a new version of make(1)! I suspect the
third thing to do is to recompile PCC, for which you need the
recompiled make. The timezone code can wait until you have the
compiler compiling itself. (I installed 4.3BSD-tahoe in many
small steps so some of this is guesswork. Indeed, I have yet to
install much of the new /usr/src.)
I suggest NOT trying the kernel until you have at least /etc and /bin
built (in /nbsd or wherever you are rooting the new tree). You will
want to run fsck to convert your file systems from old-style tables to
new, and you will probably want to label your disks (hp, ra disks only,
unless kre did the up driver); for this you will need the new /etc.
Also, the old fsck will complain about a bad superblock after running
the new kernel. (I think I managed to get this into the installation
document.)
There may be small problems with a few of the VAX Makefiles, either
with not having had `make depend' run on them, or with ()s changed
to {} (I spotted one such in adb). Note that the distributed
`mkdep' program must be able to rewrite the Makefiles. mkdep and
/bin/make have been modified to put the dependencies in `.depend',
to avoid this, but that is probably not on the distribution tape
(I have a `beta' tape so what do I know? :-) ).
Once you have the compilers going, rebuild the C library, then rebuild
/usr/src, fixing Makefiles as needed (i.e., rarely). Then a `make
install' should put everything into your new-binaries tree. If you
have not already done so, by now you are ready to try a new kernel....
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chrissean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) (09/11/88)
A few more things that I forgot about in the first posting: The Makefile for /usr/src will cause things like /etc/termcap, /etc/gettytab, and possibly, /usr/lib/sendmail.cf, to be reinstalled. If you have modified any of these, better make sure to copy them to the source directory, first, or they'll be overwritten. The BEST approach is to build the thing on a whole new filesystem, then compare the important files. Chris Torek mentioned that he approached this bit-by-bit (no pun intended); if you want to bring up a new kernel on a running system this is almost essential. Many of the Tahoe disk-related commands rely on the presence of the disk label so try and do that early in the game or it'll be headaches, later. We actually built a kernel on a different partition and booted from that before putting the system on the "root" disk. Sean McLinden Decision Systems Laboratory
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (09/12/88)
In article <4790@saturn.ucsc.edu>, haynes@saturn.ucsc.edu (Jim Haynes - Computer Center) writes: > This is not a bug report, but rather some ideas/experiences and a plea > for others to share experiences. This just seemed like the best place > to post it. Chris covered most of your questions -- it seems to me that the easiest way to install 4.3BSD-tahoe on a VAX is to recompile "make" with the NEW include files, then, go into /usr/src, and do a "make clean; make depend; make build; make installsrc". This must be run as root, as the "make depend" modifies the Makefiles themselves. This will clean, build, and install the tree (including /usr/include) for a VAX. This works, I rdist this tree to VAXen and install it myself. Remaking "make" may be a bit tricky, you might just copy the include files required into a temporary directory and use "-I." to get them. The real issue is that make needs to know what kind of machine you have, and it gets that information from /sys/machine/machparam.h. > 5. Being paranoid about security I've been going thru all the makefile > and changing modes from 755 to 711 for all the programs except shell > scripts. Also changing the owner from bin to root - this is something > of a philosophical issue, but I'd rather try to protect root against > intrusion than root and bin both. Since you can't log in as "bin" (it has no password) this shouldn't be an issue. --keith
chris@mimsy.UUCP (Chris Torek) (09/12/88)
>In article <4790@saturn.ucsc.edu> haynes@saturn.ucsc.edu >(Jim Haynes - Computer Center) notes: >>5. Being paranoid about security I've been going thru all the makefile >>and changing modes from 755 to 711 for all the programs except shell >>scripts. Also changing the owner from bin to root - this is something >>of a philosophical issue, but I'd rather try to protect root against >>intrusion than root and bin both. In article <26049@ucbvax.BERKELEY.EDU> bostic@ucbvax.BERKELEY.EDU (Keith Bostic) suggests that >Since you can't log in as "bin" (it has no password) this shouldn't be an >issue. Not only that, but if you like, you can easily give `bin' uid 0 so that the files are really owned by root. The `-m 755' (I use `-m 555' for shell scripts, just so no one edits the `binary' version of the script) is another matter; it might be nice if install defaulted to not ignoring the umask. (Perhaps -m should set the mode to arg&~umask(), while -M would set the mode to arg, so that some Makefiles could explicitly override the umask. Or perhaps they should be symbolic: `-m x' for ordinary binaries, `-m rx' for shell scripts.) In any case, I would be happier if this information were in only one place, rather than being duplicated throughout every makefile in /usr/src. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
stevens@hsi.UUCP (Richard Stevens) (09/12/88)
Does there exist a "detailed" list of what changed with the 4.3 tahoe
release ?? When we went from 4.2 to 4.3 the two documents "Bug Fixes
and Changes in 4.3 BSD" and "Changes to the Kernel in 4.3 BSD" gave us
a pretty good summary of what changed. When our tahoe tape arrived,
there wasn't anything like this. (Also, since our tape had read errors,
I had to send it back for a new one, so I haven't been able to see if
something like these manuals exists on the tape somewhere.)
We're running 4.3 with Mt Xinu's NFS, so we can't just switch everything
over, *but* there might be pieces that we should try and install.
Obviously I'm talking about user programs, not the kernel.
Chris' note about the new version of make(1) makes we wonder if there
are some significant changes to make that would be nice to have ??
Etc...
Richard Stevens
Health Systems International, New Haven, CT
stevens@hsi.uu.net
... { uunet | yale } ! hsi ! stevensjordan@zooks.ads.com (Jordan Hayes) (09/13/88)
Jim Haynes <haynes@saturn.ucsc.edu> writes:
Also changing the owner from bin to root - this is something of
a philosophical issue, but I'd rather try to protect root
against intrusion than root and bin both.
Yes, i'd like to hear about why this was (is) being done, in the latest
BSD releases and the recent SUN releases. It doesn't seem to make much
sense for some new (unprotected) user to own all the binaries.
Any input?
/jordanjordan@zooks.ads.com (Jordan Hayes) (09/13/88)
Keith Bostic <bostic@BERKELEY.EDU> writes:
Since you can't log in as "bin" (it has no password) this
shouldn't be an issue.
Yes, but root equivalence is governed by /.rhosts, but "bin" equiv. is
governed by /etc/hosts.equiv ... and we all know that "rsh csh -i" is
as good as "rlogin" for most tasks ...
/jordanhaynes@saturn.ucsc.edu ( Computer Center) (09/13/88)
Things are going surprisingly well, and I don't want Berkeley to think
I'm complaining. But here are a few more gotchas that have turned up.
Duplicate entry in file /usr/src/lib/libc/gen/malloc.c, line 95: ASSERT
Duplicate entry in file /usr/src/lib/libc/gen/regexp/regexp.c, line 142: UCHARAT
Duplicate entry in file /usr/src/lib/libc/gen/regexp/regsub.c, line 28: UCHARAT
/usr/bin/install has to be made before /usr/src/usr.lib/sendmail/aux
does a make install, because the new install and not the old one handle
multiple files to be installed in one command.
making /bin/make comes up with undefined function dirfd
doing a 'make depend', 'make clean', and 'make' fixed it, but why?
making /usr/bin/efl, complains about INITIAL redefined compiling
lex.c
making /usr/bin/eqn, complained about inability to open ${COMMON}. This
went away when I ran it again by hand, so maybe it was an artifact of
/bin/make failing to make earlier.
making routed, first must unlink /sys/machine and relink to /sys/vax,
as this is used in making routed. After fixing this it makes, but with
some warnings about can't verify arg count in '_htons' and the like.
Is this all right?
pascal had various problems. Trying a make depend; also had to change
'opc' to './opc' in several makefiles because I don't have '.' in
root's search path.lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (09/13/88)
In article <5416@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: : Keith Bostic <bostic@BERKELEY.EDU> writes: : : Since you can't log in as "bin" (it has no password) this : shouldn't be an issue. : : Yes, but root equivalence is governed by /.rhosts, but "bin" equiv. is : governed by /etc/hosts.equiv ... and we all know that "rsh csh -i" is : as good as "rlogin" for most tasks ... Not to mention NFS. You let me mount a /usr filesystem read/write with directories owned by "bin" and you've just destroyed any semblance of security. Not that NFS is all that secure to begin with... Larry Wall lwall@jpl-devvax.jpl.nasa.gov
vjs@rhyolite.SGI.COM (Vernon Schryver) (09/14/88)
In article <2841@jpl-devvax.JPL.NASA.GOV>, lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: (concerning bin owning things) > Not to mention NFS. You let me mount a /usr filesystem read/write with > directories owned by "bin" and you've just destroyed any semblance of > security. Not that NFS is all that secure to begin with... People tend to just stuff all file systems into /etc/exports, without bothering to mark them read-only. They tend to put '+' in hosts.equiv. That works fine as long as root owns everything of power, since the defaults have root not going thru hosts.equiv and being converted to some notion of 'nobody' over NFS. There is the new 'read-most' stuff in /etc/exports, but how many will use it? How many will use 'nohide' and simply export /? It may be possible to put together a secure system with bin owning things (as secure as any UNIX system), but it certainly requires more care than most users/adminsistrators are willing or able to give.
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (09/14/88)
In article <5415@zodiac.UUCP> jordan@ads.com (Jordan Hayes) writes: [ In reference to bin vs root ownership of executables ] >Yes, i'd like to hear about why this was (is) being done, in the latest >BSD releases and the recent SUN releases. It doesn't seem to make much >sense for some new (unprotected) user to own all the binaries. I prefer this for a couple of reasons. First, I don't have to give all the application programmers root access to the machine in order to install their software. Secondly, it can be a real bitch trying to install software on NFS mounted file systems if you are root. Doing this as bin doesn't get you mapped to "nobody." Third, if non-priv executables are owned by bin, it makes it easy to run a find in your bin/lib directories looking for stuff owned by root. Any differences from a list of "standard" root owned files can quickly indicate possible attempts at cracking the box. Besides, that's the way AT&T does it, and SVR4 is just around the corner :-) -- VE6BBM {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
jordan@zooks.ads.com (Jordan Hayes) (09/14/88)
Lyndon Nerenberg <lyndon@ncc.nexus.ca> writes:
[ a bunch of (lazy) reasons for wanting "bin" to own binaries ]
1) if you can't trust your hackers with an account that has install
privs on your machine, you can't trust what they are putting there.
give them a tool to install things, or keep them out of your system
source.
2) for NFS use rdist.
3) your third answer makes no sense. if you bnother at all to audit
your binaries, you should do a thorough job, and not depend on file
ownership as a sign of "tampering" ...
4) *why* does AT&T do it?
I think my question stands.
/jordanwrk@abvax.UUCP (William R. King) (09/14/88)
You will also need to manually make and install new versions of make, egrep, and install. Note that the new greps are linked together in /usr/ucb. The old ones were seperate programs and were located in /bin and /usr/ucb. Be sure to track the old ones down!. If you intend to do a make depend, you need to also install mkdep. /bill king
dls@mace.cc.purdue.edu (David L Stevens) (09/15/88)
And, of course:
1) You can turn off the root->nobody mapping. If you can't trust
the safety of root across an NFS link, why on Earth should every other
user be trusted?? Especially if root doesn't own the binaries; you're
just asking for trojan horses.
2) You can use find(1) to search for set{u,g}id bits as easily as
for any particular id; also for the r/w/x permissions, so the root ownership
per se doesn't make such searches any easier.
You clearly have to protect "bin" as much as "root", so why even
have them be separate?
--
+-DLS (dls@mace.cc.purdue.edu)chris@mimsy.UUCP (Chris Torek) (09/15/88)
In article <624@mace.cc.purdue.edu> dls@mace.cc.purdue.edu (David L Stevens) notes: > You clearly have to protect "bin" as much as "root", so why even >have them be separate? We already answered that. And, as I pointed out, if you do NOT want them to be separate, under the current scheme, you need only change one line in /etc/passwd: bin:*:3:3:Brain In Neutral:/bin:/bin/csh (I see someone has been adjusting the user names again :-) . Your uids will differ) to bin:*:0:0:Brain In Neutral:/bin:/bin/csh whereas, if you *do* want them to be separate, and they are not already, you must change every Makefile. We are thinking of fixing the `-m' value duplication (and anything else that comes up) by adding an `include' mechanism to make, a la SunOS 3.5 (which, I believe, got it from SysV). It would be nicer if make simply used m4 on makefiles, but that would break old ones, whereas adding `include' as a magic word should not. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
tanner@ki4pv.uucp (Dr. T. Andrews) (09/17/88)
There are several ways to attack system security; becoming "root" is
surely one of the most obvious. Protecting against this is certainly
a noble endeavour.
There is another possible problem, of course: the programme which
runs amok. What? You've never heard of bugs?
Finally: when something goes blooey (a user finds a hole in your
latest version of "priv_sys_hack", or a new bug in "df" tells it
to add random numbers to the free list), do you really want things
trashed?
My proposal, therefore, is that virtually NOTHING be owned by root.
Ownership by "bin" is adequate. In many cases, it will be adequate
to assure that his /etc/passwd entry for the password is "*NOLOGIN*".
Provide a nice, empty list of "trusted" systems for him in network
environments.
Further, assure that you have no "setuid" programs (other than
perhaps the local replacement for "su"). Certain progs need to poke
around in /dev/kmem, /dev/disk, or whatever: provide them with a "set
group" bit (chmod 2111 /bin/df, &c.) and arrange that the progs be
owned uid=bin/group=sys. The important files (/dev/kmem, /dev/disk,
&c.) should be owned by group "sys", and protected 0440.
Note the advantages of such a scheme (hello, AT&T; hello UCB; wakey,
wakey! i've a nice cup of fish if you'll wake up, polly parrot):
\(bu audit trail (see /etc/accton or local equiv) shows right
user id (no setuid prog to confuse issues)
\(bu amok or buggy prog can't write to anything important
\(bu you may arrange that no one is a member of group "sys"
and that the password is un-typable (try "*NOWHEELG*").
\(bu certain dangerous things, not needed by most information
producing progs (eg: df, ps), require "root" privs. if no
program has "root" privs, then your safety is increased
rather a lot.
In summary: there is really no excuse for most of the setuid "root"
progs which are distributed as part of unix. Make them setgid "sys",
protect group "sys" reasonably, and eliminate the setuid "root"
progs. The fact that most of them run setuid "root" is directly
related to laziness: no one needs to care about /dev/disk or /dev/kmem
if the program is setuid "root".
Certain directories will need to be created, and protected such that
group "sys" may scribble in them. Consider that /usr/lib/ps may get
symbol table information which makes "ps" run faster the second time
that it is run.
Oh, yes, I advise that you protect things 0111: no sense letting J
Random Luser copy (or "strings" to see what looks like a promising
hole) everything. Save disk space, prevent private copies, &c.
--
...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!cdis-1!ki4pv!tanner
or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!tanneremrath@uicsrd.csrd.uiuc.edu (09/20/88)
Huh? If I change my entry for bin in /etc/passwd from 3:3 to 0:0, files that used to be owned by "bin" will now be owned by "3" (as shown on, say, an ls -l display). There's more to it than editing /etc/passwd (which I leave to the reader as an exercise)