ghm@chem.ucsd.edu (Novice.****) (09/09/89)
I am really new to unix and was just wondering if there is a program/file or something ( for lack of better word) that allows me to know when and by whom my files have been accessed. I have tried to change the mode of the files to limit access to only myself ( at least certain personal files) but this measure seems utterly useless with superusers. Encrypting is out of the question. Can someone of the pros/experts out there give some info on the matter. I would greatly appreciate the help. Thanks Novice
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/09/89)
In article <547@chem.ucsd.EDU> ghm@chem.ucsd.edu (Novie.****) writes: > I have tried to change the mode of the files to limit access to only > myself ( at least certain personal files) but this measure seems > utterly useless with superusers. Encrypting is out of the question. UNIX generally provides no audit trail for file accesses, so you cannot tell who accessed them. You can tell when they were last accessed, however; try "ls -u". Apart from encryption or storing your files off-line, there's no way to keep someone who has superuser privilege from accessing your files. It sounds like an administrative issue to me; try talking to your site manager. If your site manager is the culprit, then perhaps you should get your own computer for your own secret stuff.
cpcahil@virtech.UUCP (Conor P. Cahill) (09/09/89)
In article <547@chem.ucsd.EDU>, ghm@chem.ucsd.edu (Novice.****) writes: > I am really new to unix and was just wondering if there is a program/file > or something ( for lack of better word) that allows me to know when and > by whom my files have been accessed. This kind of access auditing is not available under vanilla UNIX. As time goes on you will see the additions of different security features which will provide the kind of information you want (although the only person that should be allowed to review a security audit log is the system administrator or some "trusted" program). SCO UNIX is supposed to have a full C2 level security implementation which requires kernel auditing, but I have no details as to the implementation. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
barmar@think.COM (Barry Margolin) (09/10/89)
In article <1140@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >This kind of access auditing is not available under vanilla UNIX. As time >goes on you will see the additions of different security features which will >provide the kind of information you want (although the only person that should >be allowed to review a security audit log is the system administrator or some >"trusted" program). This may not be much help in the kind of situation that prompted this response. The superuser would have control over the auditing facility, and they are the ones that are the culprits. A superuser who wants to cover his tracks can do a reasonably complete job of it. If the system is C2 secure or better he wouldn't be able to hide completely, but you'd have a hard time pinning the particular infraction on him; for instance, he could turn access auditing off and on around his access to the file, but the operation of disabling auditing would have to be audited (and a C2 system is not permitted to allow even the superuser to disable this audit), so all you would know is that he did something he wanted to hide during this time. In general, it's very hard to protect oneself against omnipotent beings. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
bph@buengc.BU.EDU (Blair P. Houghton) (09/10/89)
In article <29114@news.Think.COM> barmar@think.COM (Barry Margolin) writes: >If the system is C2 secure or better he wouldn't be able to hide >completely[...] >for instance, he could turn access auditing off and >on around his access to the file, but the operation of disabling >auditing would have to be audited (and a C2 system is not permitted to >allow even the superuser to disable this audit), so all you would know >is that he did something he wanted to hide during this time. So, then, "or better" would have to prevent logging from being disabled, or would have it hardware-implemented, dumping bits into a very large place. Any good books on the subject (I ask to prevent inciting yet another discussion of secure unix systems such as the ones a few weeks ago that I never expected I'd be interested in and so used the magic k key on them... :-( )? >In general, it's very hard to protect oneself against omnipotent >beings. Especially if you are one. --Blair "And I think I speak for about half the procrastinators on the net when I say that... :-)"
cpcahil@virtech.UUCP (Conor P. Cahill) (09/10/89)
In article <29114@news.Think.COM>, barmar@think.COM (Barry Margolin) writes: > In general, it's very hard to protect oneself against omnipotent > beings. Yes. I did not intend to say that C2 is the solution to the problem with the superuser, but further levels of security (possibly B1, but more probably B2) will begin to dispense with the idea of an omnipotent being. Of course as we climb the scale, the system looks less and less like the good old unix we have come to know and love. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/10/89)
In article <1142@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >Yes. I did not intend to say that C2 is the solution to the problem with >the superuser, but further levels of security (possibly B1, but more >probably B2) will begin to dispense with the idea of an omnipotent being. And then the sysadm will merely shut down the system, boot up his browser, and examine files on the supposedly secure disk. Nothing short of an excellent encryption scheme will foil the determined snooper in a situation like the one we were discussing.
bph@buengc.BU.EDU (Blair P. Houghton) (09/11/89)
In article <11022@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <1142@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >>Yes. I did not intend to say that C2 is the solution to the problem with >>the superuser, but further levels of security (possibly B1, but more >>probably B2) will begin to dispense with the idea of an omnipotent being. > >And then the sysadm will merely shut down the system, boot up his >browser, and examine files on the supposedly secure disk. > >Nothing short of an excellent encryption scheme will foil the >determined snooper in a situation like the one we were discussing. Then, he said, change the situation. The error is in trusting "computer security" at all. Real document control is what's needed. All secure data is to remain on removable media and stored in a locked box. The person with the key to the box is not the person with the key to the drive. The other thing to remember is that almost every security situation has a single person who has the opportunity to "browse" the documents if only while walking them from the window to the cabinet, and is probably authorized to do so in order to check for missing pages, etc. As long as the superuser is a sufficiently cleared individual, then the proper security is being maintained no matter what software he can use to get into the files. As in a traditional paper system, one has to place trust in the handlers of the data. I thought the real problem was in plugging up holes that allow external communication and unauthorized access, and partitioning the access among the various groups that need to share the storage systems. That's what I read this "C2/B1" stuff to mean. I can't remember which group had that discussion originally. Was it here or in comp.misc? Will uunet have it in an archive, so I don't have to make much more of a fool of myself by covering old ground? --Blair "I hold forth, but I came in with a fifth..."
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/12/89)
In article <4113@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >As long as the superuser is a sufficiently cleared individual, then the >proper security is being maintained no matter what software he can use >to get into the files. As in a traditional paper system, one has to >place trust in the handlers of the data. If you recall how this thread started, the individual was complaining that his local super-users were abusing their powers and snooping in his private data files. The discussion about DoD trusted computing systems started with somebody's more-or-less irrelevant reply. The original situation had nothing to do with TCBs, MACs, etc.
barmar@think.COM (Barry Margolin) (09/13/89)
In article <4125@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >I recall mentioning that at the start of this thread I wasn't a superuser >and didn't even read it. Thanks for the recap. I am now a superuser, >and am interested in all forms of security. Here's most of the text of the original posting: I am really new to unix and was just wondering if there is a program/file or something ( for lack of better word) that allows me to know when and by whom my files have been accessed. I have tried to change the mode of the files to limit access to only myself ( at least certain personal files) but this measure seems utterly useless with superusers. Encrypting is out of the question. >There is _no_ way to keep the SU from looking in your files. That >is a feature, not a bug. >I tell users that if they really want me not to see their stuff >they should use encrypt(1) or move it off the machine. Note that he didn't actually ask for a way to prevent the SU from reading his file; he'd managed to discover on his own that it is impossible. He asked for a way to keep track of their snooping. The answer is that it is impossible in traditional Unix, and may be possible to a limited extent in "secure" Unix systems. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
bph@buengc.BU.EDU (Blair P. Houghton) (09/13/89)
In article <11035@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <4113@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >>As long as the superuser is a sufficiently cleared individual, then the >>proper security is being maintained no matter what software he can use >>to get into the files. As in a traditional paper system, one has to >>place trust in the handlers of the data. > >If you recall how this thread started, the individual was complaining >that his local super-users were abusing their powers and snooping in >his private data files. The discussion about DoD trusted computing >systems started with somebody's more-or-less irrelevant reply. The >original situation had nothing to do with TCBs, MACs, etc. I recall mentioning that at the start of this thread I wasn't a superuser and didn't even read it. Thanks for the recap. I am now a superuser, and am interested in all forms of security. Okay, so we're talking protection, not security. Different issue. There is _no_ way to keep the SU from looking in your files. That is a feature, not a bug. I tell users that if they really want me not to see their stuff they should use encrypt(1) or move it off the machine. I don't snoop, but I don't hesitate to look if I have a reason. --Blair "TCB? MAC? EIEIO?"
morreale@bierstadt.ucar.edu (Peter Morreale) (09/13/89)
In article <29348@news.Think.COM> barmar@think.COM (Barry Margolin) writes: >Note that he didn't actually ask for a way to prevent the SU from >reading his file; he'd managed to discover on his own that it is >impossible. He asked for a way to keep track of their snooping. The >answer is that it is impossible in traditional Unix, and may be >possible to a limited extent in "secure" Unix systems. > Actually I've heard of one way a gov't Cray site handles the issue of both security and protection. At 8am a man enters the computer room and walks to a locked cabinet. After fumbling with his keys, he unlocks the door, *rolls* out his DD-49 (disk drive) and "plugs" it in. (kinda like LA session players... "Where do ah plug in, mahnnn?") At 5pm the reverse occurs. I suspect he is not trying to crack the Coca-Cola formula. :-) Maybe that's what we need... "pluginable" disk drives. (Hard-floppy disks?... Haopply disks?...) How 'bout wizards, time to get to work? -PWM "Just another (ab)user in the wonderful world of Un*x" ----------------- Peter W. Morreale Nat'l Center for Atmos. Research, Scientific Computing Division morreale@ncar.ucar.edu (303) 497-1293
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/13/89)
In article <4125@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >I tell users that if they really want me not to see their stuff >they should use encrypt(1) or move it off the machine. That's what I told the fellow. >I don't snoop, but I don't hesitate to look if I have a reason. Make sure that your users are aware of this. I once got someone mad at me when I noticed purely by accident while investigating some system problem that a user needed to be tipped off to the fact that her files weren't totally inaccessible to others, and did so..
harrys@tons61.UUCP (Harry Skelton) (09/15/89)
Some of the security features I have installed here can catch the unsupecting
snooper pretty quick. Some of the tricks are as follows:
Front ends to the following commands ( record directory information and
other environment information for future parsing - also the arguments):
ls cat sh less more pg and others....
Monitor the processes with a deamon.
1) (if not SU) popen() a ps -ef and parse your directory information,
2) run a "strings" of memory (if possible) and grep our your
file/directory information,
3) Monitor lock files or use fuser(1?) on your files from time to time,
4) write a program to parse the proc tables and get the full arguments
to what people are running (knowledge of kernal helpful :-) ).
5) Monitor changes in files (access information, modification times, etc)
use stat() to check them and record your findings from time to time.
Be sure you understand stat() as any novice can get confused by
what happens to some of the time stamps after you have stat'ed a file.
6) Read the user's $HOME/.history file (Korn Shell) if possible. But that
will make you as bad as the other guy...
Secure your files with 000 perms and change them back when you need to read
the file or modify the file. Although SU can read it, it's still a better
way of security.
If you have access to source, you can modify the shell by adding an
audit trail fuction.
There are other ways of doing it as well, I'm sure a lot of the readers have
known about these and many more tricks. Some problems you will face are:
pg < file
- this will not show up in the 'ps -ef' listing. Only the pg will show
while read line
do
echo $line
done < file
- same here, you can bypass any security clicks in most programs
this way. Good for install disks too when you don't know what's
out there and the install disk is missing 'ls' (Hi SCO!).
echo *
- good for a munged directory listing - awk it for clean results
I'm sure you can figure out more....
BTW: anyone have source to 'vulture' or 'monitor' ?
--
Harry Skelton - harrys@tons61, guardian@ugh