> Secure logging with auditing is a decent solution.
>
> A WORM media is a nice thing, but almost no one has such a thing, so it's
> not an option for everyone..
--- True... But I wonder how long it will be before everyone has a CD-writer, or 2nd computer they could write to (that has no remote logins)? I wonder. I wonder if this would work: if you had a B/W security video recorder that only recorded frames when it detected motion (difference in input signal), then have a TV board in your computer. Have it generate a blue screen normally, then every <period:=time or space consumed> have it write to the TV board's input in such a way as to write displayable characters... Maybe the software is smart enough to read the tape back into computer format and/or it's just reviewable by watching it and looking at the time indices. Should hold tons of audit data. Just some crazy ideas, pre-coffee on a Monday morning.> > > > Nothing is safe agains an editor and someone who has root and know about > > > /dev/kmem > > --- > > On a conventional 'superuser' based system. On systems with > > least privilege/capabilities and MAC, the results less predictable. > > Why not deny root certain operations when the system is in multi-user mode > ? --- That would be one solution. The problem w/that is that there may be systems collecting and processing data 24 hrs/day -- you know, like the ones that snoop all our internet traffic (:-)) that you wouldn't want to have to take down to single user to do maintenance. Also, you might need network access to perform some tasks. I know networker likes to remotely log in as root to do automatic backups while we are sleeping. But there might be a definable set of things 'root' could be limited to do ... would take some thinking about the various tradeoffs.
> > > > Keeping the guy outside is a better start to focus on. > > --- > > > That's the perimeter defense. > > > Now what about internal containment? > > Internal cams & IR sensors (monitoring/audit). Suppose the cracker breaks > > into a 'safe'. Then they still have to crack the code to the safe door, or > > suppose different parts of the building (OS/computer) are separated by walls. > > and levels. Breaking into such a system/building is far more difficult than > > if you just have 1 really good perimeter defense on the outside. > > Agree on that one. > > > Of course can't always assume that users are always 'on the outside'. > > Sometimes they may be people who have authorized access to the system/building, > > but you don't want them able to go in all areas. Security sensors > > (ala auditing) can record who did what when -- the recording machines > > may be in a small room surrounded by guards within the NSA. No matter > > whatcha did...the steps leading up to it can be recorded. We can > > tell 'whose badge' or handprint or password authenticated them. We can > > watch them come in the front, back or side doors. We can watch them > > walking over to the security room and breaking down the door. We can > > watch them pulling the plug on the security cams. Oops -- that just > > called security. Etc. > > The system can't smell what is good and what is bad. These issue above are > company policy... --- The system can be programmed with responses. Generic ones like if luid==daemon and uid==root, and program not in {allowed set}, kill process and log event. Each company can define their own rules. The system mearly has the tools to *support* policy -- you are right in that it can't *decide* police -- but it can be programmed to *enforce* policy. We just need to make sure the features are in the kernel to support such policy.
> > Keeping userland thing secure is an important issue, restraining root > power is a second.. --- Yup. New all purpose "Root-In-A-Cage", solve those nasty root problems today! :-) > Ugh.. Had to read that 4 times.. --- That's what I get for writing while tired (a common event).
> But yes, the physical security is also of importance... ---- If the machine isn't physically secure you have nothing. Pull out the hard disks and mount them on another machine where only the cracker's policies are in effect using *their* OS. Only encoding all vital data w/1-2K encryption keys could work -- assuming key is on user's encryption dongle that plugs into an external port that is removed when computer owner isn't present (maybe it's present on their key ring). Better be sure machine is on power-backup, since it won't be able to come back up w/o the dongle. :=) Maybe keep a backup-dongle stored in a safe deposit box. Think if those laptops lost by NSA and UK folks were protected with such a mechanism -- oops, laptops lost, but all data encoded w/1024 or 2048 bit key.
That *would* likely slow things down *but*, if the alternative is no laptop, or chance of sensitive data being stolen if laptop is stolen, it *might* be worth the slowdown.
:-) -l
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:11 EST