Mike Miller wrote:

> On Tue, 10 May 2005, Richard Hoffbeck wrote:
>
>> If you look at the requirements of 'trusted computing' there is no
>> way that it can be good for OSS.
>
>
> Can't we come up with another name for it?  I think "trusted
> computing" sounds like a marketing phrase - designed to manipulate our
> feelings.  We should call it something else.  What should we call it?
>
Trusted versions of operating systems have been around for years but
were usually pitched to government users. "trusted computing" is just an
extension of that nomenclature.

>
>> The usual argument is that you can just turn off the 'trust' and run
>> Linux as usual, but the ultimate goal is to build a trusted net where
>> trusted systems will only talk to trusted systems. That certainly
>> kills spam, viruses, worms, etc. but it also leaves untrusted systems
>> only able to talk to untrusted systems.
>
>
> I don't really understand this.  If an executable file cannot be
> executed unless it is "trusted," how does that stop perl, say, from
> doing something nasty?  Perl is the executable, but it is interpreting
> a script, and the script could do bad things.  If I have a "trusted"
> computer, how does that stop me from sending an unsolicited e-mail
> message to another "trusted" computer?
>
The obvious answer would be that things like perl would either have to
go away, or be built to enforce the trust requirements. Access to system
services would be tightly controlled to keep you from doing anything
particularly nasty - this capability is already embedded in the hardened
versions of the trusted versions of SunOS, AIX, etc. If you look at
SELinux, it is capable of enforcing these types of restrictions. The NSA
specifically says that SELinux is not 'trusted' because that has a very
specific technical meaning to them, but they point out that the
potential is there to make it trusted by building the necessary
enforcement framework into the kernel and doing away with things like
the ability to turn it off.

Trusted OS's are very cool, and properly configured they will let a
sysadmin sleep soundly at night - root is just another account with no
special privileges. But they are a pain in the butt to administer so
they tend to get used in servers more than client machines. 

That brings up the other big issue with the concept of trusted
computing. If the average net user can't be trusted not to install
spyware on their machine, or run an anti-virus client, how can they be
trusted with administrative privileges to their machine? The answer is
they can't. In the MS model the administration of your machine will be
done by a third party who takes care of installing/updating software,
etc. The end user won't be given sufficient privileges to screw things
up.  I think you can also see the roadblocks that places on developing
your own software on a trusted system.

BTW, in a trusted net you certainly can send unsolicited e-mail from one
trusted host to another, but you won't be able to do it anonymously like
you can now. That makes it much easier to enforce regulations on
unsolicited e-mail because it no longer requires a lot of work to track
down the offenders, and if you add them to a certificate revocation list
you can effectively blacklist them from the network.

> I'm sure Microsoft would love to do away with TCP/IP altogether and
> replace it with MSnet, or whatever, but they'll never be able to do
> it. "Trusted computing" sounds like a move in that direction, but I
> don't see how it can work for them.
>
I'm actually pretty optimistic about trusted computing. Microsoft's
vision is a pipe dream because we simply aren't sufficiently disciplined
as developers and users to make it work. There's also the issue of
control. If you are going to have a trusted global network it implies
some global entity administering the process so we know that a US
trusted system meets the same requirements as a Chinese trusted system.
I don't see that happening soon.

On the other hand, as products like Linux, and probably OSX, start
incorporating mandatory access controls like SELinux we can get most of
the benefit without losing control to some inept international Big
Brother'.  If my server is configured to only allow administrative
privileges to specific accounts where the packets come in from a
specific interface, all sorts of exploits go away. If my mail client
runs in a very limited security context, it doesn't matter what kind of
crap you send to me because the process simply doesn't have the ability
to do anything to the system. If my system only allows administrative
access from tty1 there is nothing I can do in another session that will
effect the underlying system.

--rick