[LUAU] Intel Doubles Down on Linux

[Jim Thompson]

On Jul 20, 2005, at 5:46 PM, Tim Newsham wrote:

>> What makes you think its not Intel-dominated now?    Show of  
>> hands, please, how many in the audience here
>> run linux on anything other than an x86 processor?
>>
>
> I have a sparc running BSD and solaris (and more off topic, a  
> parisc running hpux), does this count?  No, they're not in wide  
> use.. the x86 boxen plus vmware is so much more useful :)

Yes, it counts.

>
>> Oh phleze.... X must die.
>>
>
> Hear!  Hear!

I used X in the dark ages, and it was better than a decwriter.   
Better, it took up less space on my desk than multiple glass terminals.

I remember the delight when I left X behind, with its ugliness.  I  
don't want to configure every last aspect of the UI so that I can  
work hard to make it look even uglier than the apparently color-blind  
author of the program chose.  I just want to be able to print.  Or  
pick a font.  Or have two programs work the same way.  Cut buffer,  
clipboard, WTF?!

Now, I'm so very happy to be on an OSX box, where it all seems to  
mostly Just Work without the agony of twiddling with everything to  
make the system be barely functional.

Die, X, die.  Now.  BitBlt on wheels is so last century.  I don't  
want fully generalized mediocrity.  Just have it not suck.

>> Seriously, if linux had managed to carry gnome onto raw hardware,  
>> rather than surfing the packets through an "X server", then they  
>> might have had something.   Better, if *nix had aligned around  
>> something like NeWS, then Windows would seem completely creaky in  
>> the GUI department.
>>
>
> Plan 9 got it right.  Provide a generalized system for resource  
> access (including devices), allow it to be accessed over the  
> network, and provide a device for performing graphics operations.  
> Then its just a matter of writing a simple graphics interface and  
> it can magically be used remotely (and even recursively) where ever  
> you want it.  All at miniscule sizes (by comparison). Here's to  
> good design.
>
>
>> Any computer architecture that needs "anti-virus" software has  
>> failed.
>>
>
> I'm sorry.  I have to take issue with this.  The need for anti- 
> virus software doesnt prove anything other than popularity.  There  
> is no existing security technology that can prevent virii.   
> Abstinance is the only solution.

May I suggest that you (re)-read the USGvmt's "rainbow  
books" (TCSEC), and re-familiarize yourself with the Biba security  
model?

The TCSEC has, as a central theme, the extremely strong notion of a  
Trusted Computing Base, or TCB (i.e., the implementation of the  
Reference Monitor concept).  In essence, the TCB is the central  
policy enforcement  mechanism for the computer system, mediating the  
actions of all system users and user processes.  Among the important  
characteristics of the TCB is that it be always invoked (i.e.,  
unbypassable, mediates each and every access) and self-protecting  
(i.e., cannot be modified by user code).  The  consequence of  
requiring architectures that provide such mechanisms is to limit the  
ability of hostile code to subvert the TCB.  Beginning at the C1
level of trust, fundamental protection mechanisms are required that  
provide protection of the system programs and data from unprivileged
users.  Many existing systems (e.g., PCs running DOS) lack even these  
basic protections required at C1, thus allowing a virus executed by  
any user to infect any part of the system, even those most basic to  
system operation and integrity.  WinXP goes further, and by default,  
logs itself in as something a lot like 'root' on a *nix box, putting  
the entire system at risk.

Commencing with the B2 level of trust, I expect that there will be no  
fundamental design flaws that allow the security mechanisms in the  
TCB to be circumvented.  Thus, in the absence of penetration paths, a  
virus would be limited to attacking users on an individual basis.   
This means that the rate at which it could propagate would be  
reduced, as would the damage it could inflict.

You could argue that a virus capable of infecting each and every user  
in the system (one that was present in the text editor, for instance)  
would be reasonably effective at accomplishing some missions (e.g.,  
denial of service).  Thus, the value of an intact TCB in the face of  
an otherwise completely infected user population is moot.  However,  
it is still true that a strong and self-protecting TCB, at a minimum,  
forces a virus to infect users one at a time.  It can also prevent  
some forms of attack (see Mandatory Access Control, below), and  
assure the existence and protection of the audit data by which  
viruses may be detected and traced.

In fact, a strong TCB represents the central protection mechanism  
that a  virus must overcome in order to infect the text editor in the  
first place.

Mandatory Access Control provides those mechanisms that enforce  
corporate policy dealing with the sharing of data.  Examples of such  
polices would be: "only members of the payroll staff may read or  
change payroll data," and "classified data may only be accessed by  
those having the appropriate clearances." Beginning at the B1 level,  
the TCSEC requires computer systems to be capable of enforcing MAC as  
well as DAC.  That is, the system must be able to enforce those more  
formal rules dealing with either, or both, levels of sensitivity  
(e.g., DoD classification scheme) and categories of information  
(e.g., payroll, medical, R&D, corporate planning).  Thus, the ability  
of a user to access and manipulate data is based upon the comparison  
of the attributes of users (e.g., "member of payroll department,"  
"member of R&D staff," "management," or "clearance level") with the  
attributes of the data to be accessed (e.g., payroll data, R&D data,  
classification level).  Because it is required that the TCB control  
and protect these attribute designators ("labels"), they constitute a  
"hard barrier" for a virus, effectively limiting the scope of what it  
may do; in a properly designed and implemented system a virus would  
be unable to effect any changes to the labels.  This means, for  
instance, that a virus that is being executed by someone in the  
PAYROLL department would be limited to doing damage strictly within  
the set of data that is labelled accordingly.  It would have the  
potential to modify or destroy PAYROLL data, but not access R&D or  
MEDICAL data.

Additionally, a virus could not change any labels, which means that  
it is unable to prevent PAYROLL data from being passed to anyone who  
is not a member of the payroll staff.  Likewise, a virus could not  
cause "SECRET" data to be downgraded.  In short, MAC is an extremely  
strong  mechanism, which prevents any process, including a virus,  
from making properly labeled information available to users who are  
not authorized for the information.  Systems that achieve TCSEC  
levels of B2 or greater essentially guarantee that information will  
not be "compromised," i.e., no malicious code can violate the  
restrictions implied by the labels.

It needs to be noted that the way in which mandatory controls are  
typically used is to prevent compromise, which is to say that the  
emphasis
is on preventing "high" data from being written into a "low" file.   
(Biba.)  This does not, in itself, prohibit viruses from propagating,  
either via a "low" user writing into a "high" file, or a "high" user  
importing software from a "low" file.  However, it should be noted  
further that the mandatory controls provide the opportunity for  
implementing similar controls for writing (or importation) as for  
reading.  Such controls are usually seen as implementing mandatory  
integrity policies, such that the ability to modify files is based  
upon a set of integrity labels, analogous to the classification  
labels used to regulate the reading of data.  Some systems exist  
(e.g., Honeywell SCOMP) that have implemented such mechanisms.

It may be argued that viruses present no new technical challenges.   
The attacks they carry out are the attacks that have been postulated  
since the advent of time-sharing.  However, the intellectual process  
is such that one determines a threat, or attack  scenario, and then  
develops specific countermeasures.  Thus, the classical approach has  
led us to consider attacks and develop responses on an individual  
basis.  A virus not only propagates, but may also carry out any or  
all known attacks, thus potentially presenting us with a universal  
set of attacks in one set of hostile code.

Clearly, there are no universal cures; no single set of procedures  
and technical measures guaranteed to stop any and all possible virus  
attacks.  However, this is not different from any other everyday  
security situation.  Specific mechanisms tend to be designed to  
combat  specific dangers, in the same way that vaccines are developed  
to combat specific diseases.  These preventive security measures are  
intended to raise the cost of attacks, or to make it less likely that  
a specific class of attack will be successful.  Similarly for  
viruses.  While  viruses can exploit any and all flaws in our  
computer systems and networks, they also tend to be classes of  
attacks with which we are already familiar.

Given this, while your concern for our continued vulnerability to  
virus attacks is valid, a dispassionate analysis shows that our  
previous experience in computer security is relevant - the protective  
measures and technology we have developed are directly applicable,  
and provide a good baseline for making headway against these attacks.

All this said, what is truly revolutionary about viruses is that they  
may change the way in which we will have to view the processing and  
communications support available to us, in the same way that "letter  
bombs" would cause us to radically change the way we view the postal  
system, i.e., from beneficial and useful to hostile and potentially  
dangerous.  Where we have previously put great confidence in our  
computing resources ("If the computer said it, it must be correct"),  
we will now have to consider those resources as potentially hostile.

it is here, if anywhere that we may find some solace in operating  
systems such as OSX, Linux and BSD.  Not because of their (lack of)  
mainstream popularity,  but more because they are not chock-full of a  
large number of legacy security issues, all of which not only leave  
the barn door open to potential infection, but also remain unfixed,  
because fixing them would wreck havoc in the installed base.

>> And all of this in the service of writing documents, (typically in  
>> some proprietary binary format (Word)), reading email, and surfing  
>> the web.
>>
>
> Jim, please don't stifle Bill's ability to innovate.  ;-)

We're (all) waiting for that to start.

jim