Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!bloom-beacon!eru!luth!sunic!mcsun!unido!uniol!lehners
From: lehners@uniol.UUCP (Joerg Lehners)
Newsgroups: comp.unix.wizards
Subject: Re: Is there an FSDB Manual?
Message-ID: <889@uniol.UUCP>
Date: 5 Oct 89 16:36:30 GMT
References: <1221@virtech.UUCP> <4960@cbnewsm.ATT.COM> <572@pd1.ccd.harris.com>
Distribution: comp
Organization: University of Oldenburg, W-Germany
Lines: 49

Hello !

bill@pd1.ccd.harris.com (Bill Davis) writes:
>In article <4960@cbnewsm.ATT.COM> szirin@cbnewsm.ATT.COM writes:
>>
>>Of course, anyone that can figure out how to use fsdb can easily read your
>>private file without ever touching the directory entry...

>If this were true, it would be a nasty security hole.
>Just by knowing fsdb, I could look anywhere in a file
>system and read the contents of files.

No, fsdb is not a security hole. The probabaly world-readable
character and block device special entries in /dev are the security holes.
I know about System V.2 and System V.3. In System V.2 all device
files are public readable to allow df to detremine the free block/inode
count. Maybe there are some other program that need direct filesystem
access.
System V.3 made all these special files unreadable for the normal user.
To determine the blocks/inodes count there s special systemcall.
The same things happened to /dev/mem and /dev/kmem.
System V.2: /dev/mem and /dev/kmem world readable;
System V.3: /dev/mem and /deb/kmem protected and s-bit on /bin/ps (non-root)

When fsdb is a security hole then the files in /usr/include/sys are
all security holes too, and Bach's Book 'The Design Of An Operating
System' is a security hole too. Almost all information to build
an fsdb on your own is in /usr/include/sys/* and some books.

>[a bit deleted]
>.....
>a version of Unix that lets someone other than
>root run fsdb and get information out of it (or
>worse yet, change it), perhaps you might want to tell
>your system vendor about it.  You probably don't
>want your system to remain that way.
Ok, I might be wise to protect fsdb from beeing executed by normal
user's (no problem, I think) to prevent looking at protected files.
But what about a copy of fsdb from somewhere else in some users directory ?

Get a machine and try out protecting the special files for the disks
and memory, and then do the right s-bit setting.

  Joerg
--
/ Joerg Lehners                       | Fachbereich 10 Informatik ARBI   \
|                                     | Universitaet Oldenburg           |
| BITNET/EARN: 066065@DOLUNI1.BITNET  | Ammerlaender Heerstrasse 114-118 |
\ UUCP/Eunet:  lehners@uniol.uucp     | D-2900 Oldenburg                 /