On Mon, 8 May 2000, Linda Walsh wrote:
> > 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.
*grin*
Most people have ordinary disks, no CD-RW in their computer, and I like it
that way :)
> > 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.
Some operations you probably want restricted :
- writing the kernel-memory using /dev/kmem (I'm talking the area the
kernel itself is located)
- Using chattr
- Writing directly to disk using direct IO / /dev/hdxx (and sxx)
In the highest level you may also want :
- Making sysklogd and klogd immutable
> > 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.
Nice, but that means using absolute paths in the kernel.. Yuk..
Anyone can call his app syslogd or so..
> 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).
I normally don't speak English... Only on this list :)
>
> > 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.
Works very nice. Experimented with encrypted FS.. Very usefull, especially
if you can set a inactivity-timeout, and the FS gets unmounted.
They have the hardware, but the data is useless.. No way to crack a 2048
bits key in a resonable time..
Igmar
-
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:12 EST