Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!brunix!sgf
From: sgf@cfm.brown.edu (Sam Fulcomer)
Newsgroups: comp.unix.internals
Subject: Re: Unix security additions
Message-ID: <72743@brunix.UUCP>
Date: 19 Apr 91 14:04:43 GMT
References: <6783@awdprime.UUCP> <1991Apr18.042212.11738@Think.COM> <536@playroom.UUCP>
Sender: news@brunix.UUCP
Organization: Brown University Center for Fluid Mechanics
Lines: 29

In article <536@playroom.UUCP> cliffs@gaffa.East.Sun.COM (Clifford C. Skolnick) writes:
>In article <1991Apr18.042212.11738@Think.COM> barmar@think.com (Barry Margolin) writes:
>>
>>If the people you're trying to protect against are the operators, this
>>isn't much of a solution, since they have to know the password in order to
>>do the backups and restores.

Why bother having the operator log in? Have the machines reboot at backup time,
but with the backup program switched on in the rc (or inittab, or whatever...).
After backups are done the machine can come up normally. Fine if you want to 
encrypt the dump, too. 

Restores can be done as closed logins. Build a simple app that
execs the restore and use that as the login shell. UID-0 logins are only as 
equal as their login shells after all (hey, I know, we can call it a 
"restricted shell", although I guess it shouldn't have all the holes
some do...).

>Optionally you could put the encryption in the device driver so
>that only that driver could read the tapes again.  This is a bit
>overboard unless you are really paranoid.

Ummm, oh, never mind... I guess I'm just getting old...

-- 
Sam Fulcomer	sgf@cfm.brown.edu		What, me panic: uba crazy

Associate Director for Computing Facilities and Scientific Visualization
Brown University Center for Fluid Mechanics, Turbulence and Computation