cel@uw-apl.UUCP (06/15/87)
New DoD requirements for classified computing require that we provide on demand
an audit trail from which they can reconstruct all "actions to open, close,
create and destroy classified files", Section XIII, 111.b.(4), Security
Requirements for Automated Information Systems, DoD 5220.22-M. A real UNIX
wizard will understand better than I do that this is not a trivial task in a
UNIX environment. You have to protect against access by mv, cp, rm, cat, as
well as attempts by aliased users, tasks which were linked on another system
and imported by, e.g., mag tape, etc., etc.. Is there anyone out there who has
addressed this problem seriously, let alone solved it? It doesn't seem likely
that Berkeley has done it, or will do it. [OOPS! Sorry, I forgot to mention
at the top that we're running 4.2bsd.] Send replies (even suggestions and
comments) to:
Curtis Lacy
{allegra,microvax,decvax,ucbvax!lbl-csam}!uw-beaver!uw-apl!celsnoopy@doghouse.gwd.tek.com (Snoopy) (06/18/87)
In article <175@uw-apl.UUCP> cel@uw-apl.UUCP (Curtis Lacy) writes: >New DoD requirements for classified computing require that we provide on demand >an audit trail from which they can reconstruct all "actions to open, close, >create and destroy classified files", Section XIII, 111.b.(4), Security >Requirements for Automated Information Systems, DoD 5220.22-M. A real UNIX >wizard will understand better than I do that this is not a trivial task in a >UNIX environment. You have to protect against access by mv, cp, rm, cat, as >well as attempts by aliased users, tasks which were linked on another system >and imported by, e.g., mag tape, etc., etc.. To do this right, forget about the utilities, and put logging into the kernel for the various system calls, e.g. open(2), close(2), etc. Otherwise, someone could bypass the audit by writing their own version. You would probably want the UID, the pathname, and a timestamp, possibly other things. You'll need some way to distinguish between classified files and non-classified files, to keep the volume of the log down. comment: yuck! Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
page@ulowell.cs.ulowell.edu (Bob Page) (06/19/87)
cel@uw-apl.UUCP (Curtis Lacy) wrote in article <175@uw-apl.UUCP>: >New DoD requirements for classified computing require that we provide >on demand an audit trail from which they can reconstruct all "actions >to open, close, create and destroy classified files" If 'audit trail' means a simple log of what happened to the file, when and by whom, this is not too hard if you modify the library routines to do the logging when they see some special flag in the inode. If you mean be able to reproduce any file at any point in its lifetime, it's a little bit harder than that. :-) This reponse is in the generic sense; I have not done any work in this area, nor do I know people who have. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
mjr@osiris.UUCP (06/19/87)
In article <8737@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: > In article <175@uw-apl.UUCP> cel@uw-apl.UUCP (Curtis Lacy) writes: > > >New DoD requirements for classified computing require that we provide > >an audit trail from which they can reconstruct all "actions to open, close, > >create and destroy classified files" > To do this right, forget about the utilities, and put logging into > the kernel for the various system calls, e.g. open(2), close(2), etc. > Otherwise, someone could bypass the audit by writing their own version. > You would probably want the UID, the pathname, and a timestamp, possibly > other things. You'll need some way to distinguish between classified > files and non-classified files, to keep the volume of the log down. In UNIX it's much too easy to fake that kind of thing out, though. Suppose I break into Ollie North's home directory and tar(1) it all to a file in my home directory. That logs one open(2) call for each file, and one open() call for the creation of the file in my home dir. Now, however, I have *one* file that is really an unknown number of classified files. Any further operations performed on it will seem to be working on one file. Obviously, the above example is a braindead example off the top of my head (the pointy part), but you get the idea. It's too easy to mess up your tracks as far as what you're doing and where. "cat OlliesFile | tee output" would let me read a file while appearing to only make a copy of it to disk. I did 2 open(2) and 2 close(2), and that's it, since the standard input is always open. You'd maybe have to keep track of all the devices/files open for read/write by the particular user at the time of access, as well as the number of bytes (ignoring compression) written to those devices. You could also have the shell explicitly open the standard file descriptors *EVERY* time you write to the tty. I suppose telling the spooks to go play cowboys&indians somewhere where they know what they're talking about is too idealistic ? --mjr(); -- If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I get as crude as possible. These days, though, you have to be pretty technical before you can even aspire to crudeness... -Johnny Mnemonic
meissner@dg_rtp.UUCP (06/21/87)
In article <175@uw-apl.UUCP> cel@uw-apl.UUCP (Curtis Lacy) writes: > > New DoD requirements for classified computing require that we provide on demand > an audit trail from which they can reconstruct all "actions to open, close, > create and destroy classified files", Section XIII, 111.b.(4), Security > Requirements for Automated Information Systems, DoD 5220.22-M. A real UNIX > wizard will understand better than I do that this is not a trivial task in a > UNIX environment. You have to protect against access by mv, cp, rm, cat, as > well as attempts by aliased users, tasks which were linked on another system > and imported by, e.g., mag tape, etc., etc.. Is there anyone out there who has > addressed this problem seriously, let alone solved it? It doesn't seem likely > that Berkeley has done it, or will do it. [OOPS! Sorry, I forgot to mention > at the top that we're running 4.2bsd.] Send replies (even suggestions and > comments) to: As others have said, the only real way to get the audit trail reliably, is to put it into the kernel in the open, close, shm*, bind, etc. system calls. However, the fun question is where do you log it to? Tape [you had better have fulltime operators], disk [audit trails chew up an huge quanity of disk in a hurry - I've heard of filling a 350M disk in about an hour of normal timesharing use on other systems], etc. Also, you have to watch out for set user-ID programs, etc. I don't have the orange book at home with me, but I seriously doubt whether ANY UNIX can be made more secure than B3 or maybe B2, and still have it be UNIX. In some senses, it could be said that manitory security is the antithisis of UNIX (flamers note, I mean that UNIX was designed to encourage sharing amonst it's users). -- Michael Meissner, Data General Uucp: ...mcnc!rti!dg_rtp!meissner It is 11pm, do you know what your sendmail and uucico are doing?
woerz@iaoobelix.UUCP (06/25/87)
> /***** iaoobelix:comp.unix.wiz / osiris!mjr / 7:04 pm Jun 19, 1987*/ > In article <8737@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: > > In article <175@uw-apl.UUCP> cel@uw-apl.UUCP (Curtis Lacy) writes: > > > > >New DoD requirements for classified computing require that we provide > > >an audit trail from which they can reconstruct all "actions to open, close, > > >create and destroy classified files" > > > To do this right, forget about the utilities, and put logging into > > the kernel for the various system calls, e.g. open(2), close(2), etc. > > Otherwise, someone could bypass the audit by writing their own version. > > You would probably want the UID, the pathname, and a timestamp, possibly > > other things. You'll need some way to distinguish between classified > > files and non-classified files, to keep the volume of the log down. > > In UNIX it's much too easy to fake that kind of thing out, though. > Suppose I break into Ollie North's home directory and tar(1) it all > to a file in my home directory. That logs one open(2) call for each > file, and one open() call for the creation of the file in my home > dir. Now, however, I have *one* file that is really an unknown > number of classified files. Any further operations performed on it > will seem to be working on one file. > > Obviously, the above example is a braindead example off the top of > my head (the pointy part), but you get the idea. It's too easy to > mess up your tracks as far as what you're doing and where. > "cat OlliesFile | tee output" would let me read a file while appearing > to only make a copy of it to disk. I did 2 open(2) and 2 close(2), > and that's it, since the standard input is always open. > > You'd maybe have to keep track of all the devices/files open for > read/write by the particular user at the time of access, as well as > the number of bytes (ignoring compression) written to those devices. > You could also have the shell explicitly open the standard file > descriptors *EVERY* time you write to the tty. > > I suppose telling the spooks to go play cowboys&indians somewhere > where they know what they're talking about is too idealistic ? > > --mjr(); > -- > If they think you're crude, go technical; if they think you're technical, > go crude. I'm a very technical boy. So I get as crude as possible. These > days, though, you have to be pretty technical before you can even aspire > to crudeness... -Johnny Mnemonic > /* ---------- */ It's even more complicated in UNIX. Tar opens the file and you get a log. But consider dump. It opens the raw device of the disk and copies the raw block to tape or to another location. I think it is nearly impossible to protect someone from reading the raw disk under UNIX. You can write a log entry from dump, but I think you cannot protect against someone reading the raw disk with his own programs. ------------------------------------------------------------------------------ Dieter Woerz Fraunhofer Institut fuer Arbeitswirtschaft und Organisation Abt. 453 Holzgartenstrasse 17 D-7000 Stuttgart 1 W-Germany BITNET: iaoobel.uucp!woerz@unido.bitnet UUCP: ...{seismo!unido, pyramid}!iaoobel!woerz
dhb@rayssd.RAY.COM (David H. Brierley) (07/04/87)
In article <8300007@iaoobelix.UUCP> woerz@iaoobelix.UUCP writes: > >It's even more complicated in UNIX. Tar opens the file and you get a >log. But consider dump. It opens the raw device of the disk and >copies the raw block to tape or to another location. I think it is >nearly impossible to protect someone from reading the raw disk under >UNIX. You can write a log entry from dump, but I think you cannot >protect against someone reading the raw disk with his own programs. > Protecting normal users from reading the raw disk is not only easy, it is essential to system security. All block and character device entries for the various disk drives (i.e. /dev/rhp0a, /dev/rra0a) should be made mode 600 and owned by either root or some other "secure" account. If the raw disk is readable by general users it effectively overrides any file permissions that other users might set up. I strongly suggest that any system administrators who are not sure about this check the device entries to make sure the permissions are set correctly. -- David H. Brierley Raytheon Submarine Signal Division 1847 West Main Road Portsmouth, RI 02871 Phone: (401)-847-8000 x4073 Internet: dhb@rayssd.ray.com Uucp: {cbosgd, gatech, linus, mirror, necntc, uiucdcs} !rayssd!dhb
jerry@oliveb.UUCP (07/09/87)
In article <1110@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David H. Brierley) writes: >Protecting normal users from reading the raw disk is not only easy, >it is essential to system security. All block and character device >entries for the various disk drives (i.e. /dev/rhp0a, /dev/rra0a) >should be made mode 600 and owned by either root or some other "secure" >account. If the raw disk is readable by general users it effectively >overrides any file permissions that other users might set up. Actually you should consider making them mode 640, owned by root and with group set to the group your operators are in. This allows them to do dumps without being root. Of course this depends on the procedures you use for backup but it can add an extra measure of security. The /dev/mem and /dev/kmem entries are another area that should have similar protection. On 4.3BSD they are mode 640 with a group of "kmem". This allows programs like "ps" to be set group id to kmem instead of set uid to root. Jerry Aguirre
haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) (07/09/87)
> >Actually you should consider making them mode 640, owned by root and >with group set to the group your operators are in. This allows them to >do dumps without being root. Of course this depends on the procedures >you use for backup but it can add an extra measure of security. Or, it can detract from security if people can find a way to get into the operator group when they don't belong there. (e.g. they learn some operator's password). What we did instead is to have a 'backup' account on the machine that the operators log into when they are going to do backups. The dump program is hacked so that it runs setuid root, but drops privileges if the uid running it is not that of 'backup' . haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes
daveb@geac.UUCP (Dave Brown) (07/11/87)
In article <1894@oliveb.UUCP> jerry@oliveb.UUCP (Jerry F Aguirre) writes: >The /dev/mem and /dev/kmem entries are another area that should have >similar protection. On 4.3BSD they are mode 640 with a group of "kmem". >This allows programs like "ps" to be set group id to kmem instead of >set uid to root. In general, it is better to have a few groups who "own" particular resources than have every type-manager program use setuid root. If you create several hundred groups, though, you can expect to see a performance problem (:-) -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
scc@cl.cam.ac.uk (Stephen Crawley) (07/16/87)
>> In article <8737@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: >> Suppose I break into Ollie North's home directory and tar(1) it all >> to a file in my home directory. That logs one open(2) call for each >> file, and one open() call for the creation of the file in my home >> dir. Now, however, I have *one* file that is really an unknown >> number of classified files. Any further operations performed on it >> will seem to be working on one file. >> >> Obviously, the above example is a braindead example off the top of >> my head (the pointy part), but you get the idea. It's too easy to >> mess up your tracks as far as what you're doing and where. I'm not sure I DO get the idea ... In logging the open("/usr/ollie/secret", R) the security system has recorded the fact that you have breached security for that particular file, and that you have (probably) read it. Unless you were logged via a terminal in a secure room, and the a security guard strip searched you on the way out (to check for minature cameras, etc), the authorities must assume that you could still have a copy somewhere even if they can guarantee that they have found all of your online copies. In short, your messing up your tracks doesn't help you at all and it only hinders the "fire fighters" a bit. It is a different matter if you are talking about person A with legitimate read access to a file leaking a copy to person B who is on the other side. A secure system would need to do far more than logging file access to detect that sort of thing! In article <8300007@iaoobelix.UUCP> woerz@iaoobelix.UUCP writes: >> /***** iaoobelix:comp.unix.wiz / osiris!mjr / 7:04 pm Jun 19, 1987*/ >... consider dump. It opens the raw device of the disk and >copies the raw block to tape or to another location. I think it is >nearly impossible to protect someone from reading the raw disk under >UNIX. You can write a log entry from dump, but I think you cannot >protect against someone reading the raw disk with his own programs. The first thing a security conscious UNIX system administrator would do would be to set the access on the raw (and block) device files for the disc so that it can't be read by mere mortals. Then he would do the same for /dev/kmem etc ... -- Steve Disclaimer: I don't know what I'm talking about, but sometimes I listen to people who do.
greywolf@unisoft.UUCP (The Grey Wolf @ ext 165) (07/23/87)
In article <735@jenny.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: >>> In article <8737@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: >>> Suppose I break into Ollie North's home directory and tar(1) it all >>> to a file in my home directory. That logs one open(2) call for each >>> file, and one open() call for the creation of the file in my home >>> dir. Now, however, I have *one* file that is really an unknown >>> number of classified files. Any further operations performed on it >>> will seem to be working on one file. >>> >>> Obviously, the above example is a braindead example off the top of >>> my head (the pointy part), but you get the idea. It's too easy to >>> mess up your tracks as far as what you're doing and where. Why log system calls in the first place? I object to it in two ways: 1) The kernel overhead and resulting system load would SKYROCKET, resulting in a slower machine. 2) While it may make the machine more "secure", a proper system administrator should be on top of things to begin with. If users get this feeling that "Big Brother Is Watching You", they're going to feel a lot less comfortable using the machine. I know I would. Granted, there are mischievous sorts and malevolent sorts (I wouldn't mind the mischievous sorts on my machine--they make life interesting!), but I believe in freedoms, not restrictions, and I believe in privacy. Never mind that the Big Brother thing is practically happening in real life, that's not the issue... What am I trying to say? I guess I'm not quite sure. But I am sure that I don't like to see freedoms violated like they would be. Sure, the honor system doesn't always work, but when it does, people in the environment in which it is used are more appreciative of what they have going for them there. EOF (End Of Flame) Roan (RO'an) Anderson unisoft!greywolf -------------------------------------------------------------------------------- Faster than pure assembly code... More powerful than kill -9... able to unmount busy file systems in a single call... ______ it's a (long) word... / | | \ it's a (back)plane... \=#==#=/ \| |/ it's... \==/ \/ SUPERUSER!!!! ------------------------------------------------------------------------------
smb@mimsy.UUCP (Steve M. Burinsky) (07/24/87)
In article <468@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >2) While it may make the machine more "secure", a proper system administrator >should be on top of things to begin with. If users get this feeling that >"Big Brother Is Watching You", they're going to feel a lot less comfortable >using the machine. I know I would. Granted, there are mischievous sorts and >malevolent sorts (I wouldn't mind the mischievous sorts on my machine--they >make life interesting!), but I believe in freedoms, not restrictions, and I >believe in privacy. Never mind that the Big Brother thing is practically >happening in real life, that's not the issue... > What am I trying to say? I guess I'm not quite sure. But I am sure > that I don't like to see freedoms violated like they would be. > Sure, the honor system doesn't always work, but when it does, people > in the environment in which it is used are more appreciative of > what they have going for them there. > > Roan (RO'an) Anderson > unisoft!greywolf You're kidding, right? 1984 came and went without any thinkspeak. Big Brother is watching? Come on -- if you can't handle an accountablility record of what users are doing, don't use the machine. Remember, this is about UNIX classified operation. If you can't sleep at night knowing that you might be watched when you log on the next day, tell Big Brother to keep his security clearance. "a proper system administrator should be on top of things to begin with." This obviously didn't happen in [Johnathon Pollard, Arthur Walker, Larry Chin, Christopher Boyce, and on and on and on and on ...]'s case. "Sure, the honor system doesn't always work, but when it does..." This accountability has nothing to do with "when it does", but when it doesn't. Because the honor system doesn't always work, you need to do some checking. Do you toss and turn at night because Big Brother is reviewing the zillions of dollars of electronic fund transfers just to make sure that no one is swindling a few million here and there? Should the IRS just take everyone's word that their tax return is completely correct? Without this checking, abuse can become rampant. Relax. Big Brother could generally care less what it is you do or say or think. They just don't have time to. It's when someone gets out of line that it matters. -- Steve M. Burinsky smb@mimsy.umd.edu
mjr@osiris.UUCP (Marcus Ranum) (07/24/87)
In article <468@unisoft.UUCP>, greywolf@unisoft.UUCP (The Grey Wolf @ ext 165) writes: > Why log system calls in the first place? I object to it in two ways: > 1) The kernel overhead and resulting system load would SKYROCKET, resulting > in a slower machine. [... drivel deleted...] > What am I trying to say? I guess I'm not quite sure. But I am sure > that I don't like to see freedoms violated like they would be. [... drivel deleted...] If you had followed the original discussion, rather than jumping in half-cocked, you would have known that the discussion was in reference to the spooks requesting that UNIX provide them with exactly the type of audit trails you are so offended by. Most of the postings, including my example about Ollie's files (though they are actually on an IBM, I learned) were describing the utter stupidity of the idea. I think that most people who are familiar with the real world and UNIX know what a dumb idea the whole thing is. Most people who live in the real world also realize that what the spooks want, the spooks get, since they pay a lot of people's salaries. This type of boneheadedness will all be done on secure UNIX systems, anyhow, and hopefully only a very few of us will ever have to try to get any work done on them. --mjr(); -- If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I get as crude as possible. These days, though, you have to be pretty technical before you can even aspire to crudeness... -Johnny Mnemonic
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/25/87)
In article <1335@osiris.UUCP> mjr@osiris.UUCP (Marcus Ranum) writes: >This type of boneheadedness will all be done on secure UNIX systems, anyhow... Not necessarily. Another, technically much superior approach to classified computing is to operate the system inside a physically controlled area (vault). That's actually the approach that BRL seems to prefer, rather than crippling our systems so that perfectly reasonable application needs can no longer be effectively met (which is what the Orange Book would have you do). Government regulations in general appear to be written by people who have insufficient input from the working level that the regulations would directly impact. So long as the politicians continue to think that they have some special ability to fix problems by administrative fiat, this situation wessiessie FL
preece%mycroft@gswd-vms.gould.com (Scott E. Preece) (08/05/87)
In article <468@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: > ... but I believe in freedoms, not restrictions, and I >believe in privacy. Never mind that the Big Brother thing is practically >happening in real life, that's not the issue... ---------- The point to the "Big Brother" logging and controls on secure systems is to protect privacy. Now, you may think it's good for you to have privacy and bad for government agencies to have privacy, but that's an entirely separate issue from whether it's a good thing for a system to be able to enforce it. I kind of like the idea of the system being capable of protecting me from intrusions, even if part of the cost is a level of activity logging that makes it possible to be even more intrusive, so long as nobody I don't trust has access to that log data. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@Gould.com