Security vs. Maintenance

[Paul Prescod]

This is just a side point, related to the issue of security (but not
really, as I hope to make clear). It isn't a disagreement with anything
Fare said.

Fare Rideau wrote:
> 
> An interesting thread lately was about security under LispOS.
> If we want LispOS to be a usable system in a networked world,
> we must seriously address security issues.
> 
>    It would be too bad that the slightest mistake from a lisper,
> whether at a console, or in a program, or through the network,
> would crash the system, destroy or modify important data, etc.

I think that it was convenient to "tie" security and system maintenance
as Unix does, but I would like to encourage us to think if them as very
separate. The implementation model for the two may share charcteristics
(as it would under Fare's proposal) but I do not think that the security
system should be used as an excuse to make maintenance of the machine
difficult and dangerous as it is in Unix. I'm not suggesting that Fare
is proposing this but since most of us spend most of our time with Unix
today I think it is worth taking a hard look at carefully.

Let's take an example:

Under Windows 95 I can delete my "Windows directory". That's bad news.

Under Unix, I cannot delete my /etc or /bin directory unless I am
running as root. That's good news.

But under Unix I *can* easily delete my ~ directory irrevocably and
unretrievably. That's bad news.

I think that the data in ~ is just as important than the data that runs
the computer. I can download new /bin files, for instance. /etc is
harder to recover, but the files change less often (on my computer at
least) so backups are more likely to be useful. Your mileage may well
vary. The important point is that the Unix point of view devalues the
importance of user files and overvalues (maybe) the importance of system
files.

The real question is: why is it so bloody easy to blow things away and
why is it so hard to get them back? The OS should be smarter. Almost
everything should be reversible. Some things will, by necessity be not
reversible. The OS should ask the user: "do you really want to delete
your system files? Those are non-recoverable." If the user feels
competent he or she should switch into "no warn" mode (a user interface
mode), rather than "login as root" (a security mode). But the set of
things that are irrecoverable should be small enough that these types of
warnings are rare (basically just: "Do you really want to dump this
garbage object bin?")

That means that novice (or tired, or merely human and therefore
fallible) LispOS users will be able to maintain their own machines and
know when they are about to do something that they should think twice
about. Since almost everyone in the world will be a novice LispOS user,
this seems very important to me. They should feel free to explore and
have a simple way to know when they are reaching the boundaries of what
is safe. Further, those boundaries should be rare, unlike Unix where the
difference between a relatively safe command and a dangerous one is
frequently one keystroke. I feel very strongly that the Unix model is
wrong. The world does not divide cleanly into two groups of people:
those that are competent to maintain their machines and can be trusted
as root and those who do not and cannot. Everybody should be able to *at
least try* to maintain their machines and the cost of making a mistake
should not be disaster.

Fare's idea of an execution context seems to be flexible enough to allow
this distinction by making filtered commands available in to some users
(administrators), completely unavailable to others and available without
interaction to confident users and non-interactive processes with
sufficient execution rights.  I think it should be combined with some
form of global "undo log" that can rollback a system or system component
to a previous stage if something goes wrong. Or even if the log is not
global and maintained by the OS itself, it should be considered bad
LispOS programming to make anything that is not trivially undo-able.

To sum: Whether or not we adopt Fare's proposal I would like to see
security and system maintenance be too important, perhaps related, but
ultimately distinct concerns and the security system should not be used
to make up for the inefficiencies of the maintenance UI and features.

 Paul Prescod