"Juanjo ?lvarez" <juanjo@nospamplease_juanjoalvarez.net> wrote in message news:csf8qi$5jm$1@digitaldaemon.com...
> On 2005-01-16, Thomas Kuehne <thomas-dloop@kuehne.cn> wrote:
>>> Also please note that free software would be one the the very bad things (for Microsoft) that Palladium could stop.
>>
>> The basic concept of assigning access rights based on "trust" is quite usefull.
>
>> (On one of my system only executeables with an embedded valid & trusted
>> GPG signature are
>> allowed to be loaded.)
>>
>> The problem with Palladium is how the "trust" is managed.
>>
>> 1) The local administrator isn't in controll. This leads to lots of legal
>> problems
>> - at least here in Old Europe.
>> 2) Online access is required.
>
> And probably:
>  3) To obtain a certificate for your software that works with Palladium
>  hardware you must pay Microsoft (or Intel or...), for every new
>  version and minor release.
>
>> Many of todays Bad Soft(tm) are working on the script level. I'm sure IE,
>> OE and MsOffice
>> will be trusted ...
>
> Sure.
>

and this is EXACTLY what i was refering to as misused power.
this is the reason i prefer viruses over someone telling which files i am
allowed to load or not.
especially when it's MS and Intel in charge.
and i mean hey, if MS has no bugs in their software, i'm that the hardware
will be perfect !

- Asaf.

Problem is that no only does the Language have to support but the OS and as people have said they don't want the OS to control that aspect. If and only if the OS can store the checksum in a secure location that only the OS can access, then I would say it is a good idea. Actually, I think this idea would be better if it was implemented in the OS anyway, since the OS controls memory access (in most cases) and should be able to seek out attacks.

If it is stored in the Registry, then it would be more of a burden than anything useful. Another problem is that some programs are updated and are dynamic so how does a program update their checksum or would the OS update the checksum? If the OS updated the Checksum then how does it know that it wasn't a virus that changed something. Microsoft probably won't be doing this... ever, even if they did rewrite the OS.

it's probably doable as a hooking into CreateProcess or something..
you can inject code that will have a certain checksum (if the file is
on a registered files list or whatever..)
the problem is to control it in a way that won't dramatically decrease
the OS preformance.

and it's a HUGE pain in the ass. (code injection into the kernel and all..)
- Asaf.

"Gold Dragon" <dragonwing@dragonu.net> wrote in message news:csg0ue$v3d$1@digitaldaemon.com...
> Problem is that no only does the Language have to support but the OS and as people have said they don't want the OS to control that aspect. If and only if the OS can store the checksum in a secure location that only the OS can access, then I would say it is a good idea. Actually, I think this idea would be better if it was implemented in the OS anyway, since the OS controls memory access (in most cases) and should be able to seek out attacks.
>
> If it is stored in the Registry, then it would be more of a burden than anything useful. Another problem is that some programs are updated and are dynamic so how does a program update their checksum or would the OS update the checksum? If the OS updated the Checksum then how does it know that it wasn't a virus that changed something. Microsoft probably won't be doing this... ever, even if they did rewrite the OS.

I'd rather have the checking done by the operating system.
If you can't trust the operating system, then no checking
of any kind is worthwhile. (So this issue is not relevant
to products from Redmond.)

Programs should come with chekcsums in a separate file,
and those checksums should also be on the net, for
manual checking.

Normally the operating system would checksum an executable
each time it is invocated. Any modification to the file
at runtime should be an "exe in use" exception.

On the other hand, if you have an operating system that
is trustworthy, then your main enemy would mostly only
be trojans. This could be taken care of if every single
executable or dll would have to be signed. The trojan
manufacturer would then either have to sign the code, or
forge it in some (hopefully) labourious way.

This leaves trojans hidden in source code distributions.
So these could be forbidden.   :-)

Seems we're more than skin deep in trouble. And are
going to stay that way.


Norbert Nemec wrote:
> Manfred Nowak wrote:
> 
> 
>>Norbert Nemec wrote:
>>[...]
>>
>>>Post-processing executables for specific purposes can be done
>>>perfectly well in a separate stage after compilation.
>>
>>Is this a defintion? That would mean, that those tasks that cannot be done
>>perfectly well in a separate stage after compilation have to be built into
>>the compiler. Is it imperfect enough if you have to renanalyze the just
>>generated program to find the places where you are able to insert
>>checksums and routines for checking, thereby increasing the needed
>>cpu-time from one unit to at least units in the order of the length of the
>>program?
> 
> 
> OK, if the checksum - or whatever - algorithm goes so deep into the
> structure of the program, it would make sense to build it into the
> compiler.
> 
> 
>>>Modularity seems a far better approach, unless
>>>the individual stages are inherently interconnected.
>>
>>So please explain what the currently implemented release option is doing
>>that is inherently interconnected with the compiling phase and cannot
>>perfectly well be done in a separate stage after compilation.
> 
> 
> I'm not sure what you mean with "release option". If you talk of "release"
> vs. "debug" mode, then this option is not a separate stage after
> compilation but an option that affects the code generate stage.
> 
> In any case: I still think, that self-checking binaries should be left as a
> separate project. There are many different purposes for checksumming of
> binaries (protection against viruses, intrusion, general corruption,
> probably many more) Finding one "general purpuse" checksumming method will
> result in something that is suboptimal for at least some of the purposes.
> If a system administrator has special need for checksumming, it should be
> up to him to decide on the details. In any other case, checksumming would
> just cost space and performance with little gain. (Actually, for my
> personal machine under Linux, I see no point why certain applications
> should be self-checking. If I knew that every binary is self-checking,
> there might be a certain gain, but if it is depending on the programming
> language, the feature is mostly worthless.
>