Approved application execution (was Re: [Leaplist] Why Open Source won't work on "Vista computers")

[Bill Anderson]

On Wednesday 27 December 2006 13:47, Phil Barnett wrote:
> > I think that it is better to address bad software at the level
> > of the bad software, which includes some poor default
> > configurations I've seen on both Windows and some
> > Linux distros.
>
> Bad software is seldom an issue of configuration. It's buffer overflows,
> back doors, trojan, attack vectors, etc. Things I'll never be able to
> control.

Definitely. If it takes a particular configuration to work around a flaw, it 
is bad software, IMO. Indeed I would take the next step and say that 
configuration options to work around known security holes indicates really 
bad software of the "yeah we know it's broke but don't want to fix it' 
variety.

As far as the "only run approved software" bit, is seems to me a relatively 
simple route (note I didn't say easy. :) ) would be a kernel module that read 
a list of pethandfilename/*sum (md5sum, checksum, shasum whatever you choose) 
pairs, and followed this decision tree:

full-path-and-filename in approved list?
No -> Access Denied
Yes -> Check the *sum.

Does the *sum match?
No -> Access Denied
Yes -> Execute as requested

Sure it would slow the start of new process some, but it seems workable. May 
not be pretty, or easy, but conceptually workable. This would not require any 
third party certifications. The distribution would provide the necessary file 
for installed applications (perhaps the installer could even generate ones at 
install time to add), and a relatively simple TUI/GUI could be provided for 
the sysadmin to manage what is allowed to run.

Since no third party certification is required, the sysadmin could write new 
scripts and run a command line tool to add it to the database. One could also 
go the overkill route and also maintain a list of bad sums that would be 
expressly denied. By logging to syslog and using a syslog monitoring process 
to watch for denied events and send alerts you could have "real-time" 
monitoring of such attempts. 

Obviously since I have not implemented this (I have implemented a real-time 
fs-monitoring system though) I don't know what performance hit it would 
provide. And as always the devil is in the details of implementation - does 
the implementation code provide a whole?

This combined with real-time monitoring should provide a reasonably secure 
system for the average user. Seems to me this shouldn't be difficult for MS 
to do on their systems as well. Nor does it have to be distribution-specific.

Note that at no time does the application itself contain any information about 
what the user is allowed to do, so it isn't DRM in any way.

Is it my "I thought of this just now" bias or does this appear to satisfy both 
of you two's desires? It would pretty much solve the trusted application 
issue while still leaving the sysadmin in full control. It would not require 
third party "certifications" and this not unduly benefit Verisign. And it 
does nothing in favor of DRM of any kind  other than "it's my system and I 
reserve the right to say what can run on it" of course.

You know, it's been years since I've touched kernel code. But if we have any 
kernel-hackers here I'd be interested in working with them to produce a 
module and utilities for it. Come to think of it, combined with my real-time 
FS monitoring it could be really cool. Then again I'm sure there are wholes 
in the concept somewhere and I've not taken the time to look for them yet.

Would it solve an existing problem? Some would say yes, others no. But as it 
would be entirely optional it shouldn't matter. For some it does solve a 
current problem, but this problem for others is merely yet to come. If we can 
solve it before we become a prime target, before we have millions of "Joe 
Endusers" to migrate, we can be a good step ahead for a change.

Cheers,
Bill

Cheers,
Bill