[ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Makan Pourzandi]

Hi all,

DSI development team would like to announce the release 0.2 of digsig.

This kernel module (for 2.5.66 and higher) checks
the signature of the binary before running it.  The main goal is to 
insert digital
signatures inside the ELF binary and verify this signature before
loading the binary. It is based on the Linux Security Module hooks.

The code is GPL and available from: http://sourceforge.net/projects/disec/,
download digsig-0.2.

I hope that it'll be useful to you.
All bug reports and feature requests or general feedback are welcome 
(please CC me in your answer or feedback to the mailing list).

Regards,
Makan Pourzandi


overview
=======

Instead of writing a long detailed explication, I rather give you an 
example of how you can use it.

A Very simple scenraio to show how to use it  
=======================================

1) Generate gpg key and export your public key in order to use it for
 signature verification.
 
$gpg --gen-key

=> careful generate RSA key

$gpg --export >> my_public_key.pub

2) Sign your binaries using Bsign

Before using bsign to sign all your binaries, try out with a simple
example.

$cp `which ps` ps-test
$bsign -s ps-test // sign the binary
$bsign -v ps-test // be sure that the signature is valid  

3) Make the digsig module

 From ./digsig, do make -C /usr/src/linux-2.5.66 SUBDIRS=$PWD modules. 
You need rw acess to /usr/src/linux-2.5.66.

CAREFULL: we advice you to compile the module in debug mode at your
first tries (see -DDSI_DEBUG -DDSI_DIGSIG_DEBUG in the Makefile). In
this mode, the module verifies the signatures but does not enforce the
security (if not any signature present in your binary, you'll have a
message in /var/log/messages but the execution is not
aborted.). However, the execution of the bianaries with invalid
signatures is aborted. Once, you're sure of your binary signature
procedure you can recompile the whole on non-debug mode.

4) load digsig, use the public key exported in step 1 as argument

root@colby digsig-dev]# ./digsig.init start pubkey.pub
Loading Digsig module.
Making device for communication with the module.
Loading public key.
Done.
root@colby digsig-dev]#

5) In debug mode:

$./ps-test

$tail -f /var/log/messages
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - binary is ./ps-test
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds: 
Found signature section
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - dsi_bprm_compute_creds: 
Signature verification successful

$ps

// no check for not signed binaries
$tail -f /var/log/messages
Sep 16 15:49:16 colby kernel: DSI-LSM MODULE - binary is ./ps


6) In restrictive mode, normal mode

You need to use bsign to sign all binaries that you want to run in
normal mode.

// signed binary
[lmcmpou@reblochon lmcmpou]$ ps
  PID TTY          TIME CMD
 6897 pts/2    00:00:00 bash
 6941 pts/2    00:00:00 ps

// not signed binary
[lmcmpou@reblochon lmcmpou]$ ./ps-makan-1
bash: ./ps-makan: cannot execute binary file

// binary with wrong signature
[lmcmpou@reblochon lmcmpou]$ ./ps-makan-2
bash: ./ps-makan-colby: Operation not permitted

7) Unload the module.

[root@colby digsig-dev]# ./digsig.init stop
Unloading Digsig.

Performances
===============

This is release 0.2. We have done some benchmarks.

We ran lmbench on a Pentium IV, 2.4 GHz, 500 mega bytes of memory,
running Linux 2.5.66. Our benchmarks show that the execution time
(exec function call) multiplies by a factor of 4 when the module is
loaded (no changes for fork call, as the binary is not loaded into
memory).

Some details
==========

The module is independent from DSI (parent project) and you don't need 
to download
the whole dsi tar ball to play with the digsig module (even if we'll be 
more
than happy to have your feedback about dsi project :-)).

Our approach has been to use the existing solutions like gpg and bsign
rather than reinventing the whole thing from scratch.

However, in order to reduce the overhead in the kernel, we took only the
minimum code necessary from GPG. We took only the MPI (Multi Precision
Integer) source code and the RSA crypto source code. This helped much
to reduce the amount of code imported to the kernel in sourc code of
the original (only 1/10 of the original gnupg 1.2.2 sourc code has
been imported to the kernel module). On the other hand, we avoided
OpenSSL source code for the fact that the licensing was not clear to
us. We did some tests at user level and found out that OpenSSL is 4
times faster than GPG regarding RSA verification. As a future
direction, we plan to clarify this licensing issue and use OpenSSL
instead of GPG.

Requirements:
==============

Linux OS kernel 2.5.66 or  higher. We tested against 2.5.66 and 
2.6.0-test5.

Bsign version
0.4.5. (http://packages.debian.org/unstable/admin/bsign.html)

GPG 1.2.2 or higher.

Merits
=====

This work has been done by (alphabetical order)

A Apvrille (axelle.apvrille@ericsson.ca),
D Gordon (davidgordonca@yahoo.ca),  
M Pourzandi (makan.pourzandi@ericsson.ca),
V Roy (vincent.roy@ericsson.ca).

Special merits go to David who wrote big chunks of the source code.

Thanks to Radu Filip (socrate@infoiasi.ro) which has done the initial 
study for this work.

Thanks also to Marc Singer who helped us in using Bsign.

Regards,
Makan Pourzandi
-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada      makan.pourzandi@ericsson.ca
This email does not represent or express the opinions of
Ericsson Inc.
-------------------------------------------------------

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Pavel Machek]

Hi!

> overview
> =======
> 
> Instead of writing a long detailed explication, I rather give you an 
> example of how you can use it.

Can you also add example *why* one would want to use it?

AFAICS if I want to exec something, I can avoid exec() syscall and do
mmaps by hand...
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Makan Pourzandi]

Pavel Machek wrote:

>Hi!
>
>  
>
>>overview
>>=======
>>
>>Instead of writing a long detailed explication, I rather give you an 
>>example of how you can use it.
>>    
>>
>
>Can you also add example *why* one would want to use it?
>  
>
>AFAICS if I want to exec something, I can avoid exec() syscall and do
>mmaps by hand...
>

Hi,

Thank you for your feedback. This is my understanding of the situation, 
if I'm wrong in my analysis, let me know.

There are different answers to this question because there are many 
possible attack scenarios. I try to take the most realistic one and give 
a short answer.  

For the attacke described by you to be successful, one assumes that the 
intruder  gained access to the system,  he wrote his own code on the 
system (or brought it in),  and compile  it on the system (cannot 
execute its own code as it is not signed), produced the binary to mmap 
the malicious code to the memory, and run the code that call syscall 
mmap.   

First digsig can help to avoid the access to the system by the intruder. 
as it aborts the execution of malicious code which often leads to a root 
access for the intruder.

Second, digsig can avoid the execution of the binary that allows to 
bring in the code or other malicious binaries. AFAIK, the intruders 
generally use their own binary to download malicious code. This is 
because in hardened systems, the use of ftp ot other alike binaries, 
(when these binaries are not completely removed from the system for 
security reasons) is closely monitored and controled through firewalling 
rules. Even in simple desktops, it is rather easy to control the use of 
ftp and alike to track down the intrusion source.  therefore, the 
intruder needs to run  his own binary to download the root kit which is 
avoided by the use of digsig.

Third, the intruder now has access to the system, he cannot execute the 
code he brought in with himself (not signed) or he cannot bring it in 
(c.f. above). So he needs to compile the code on the system. AFAIK, for 
the absolute majority of servers the admins remove all compilers 
(specially gcc) on all servers. this is for several different security 
reasons  (I don't want to get there). therefore, the above hypothesis 
gets even more difficult to realize. 

Last, but I believe the most important, the level of difficulty of 
execution of such an attack is much higher than the average knowledge 
level of many script kiddies. The absolute majority of attackers have 
little or absolutely not any knowledge of the operating systems in 
general and linux in particular, let aside the knowledge of writing a C 
program, calling mmaps in that progam and run the malicious code to gain 
access as root, then remove the module to execute a classical attack.

There is no such thing as 100% secure system, digsig increases the level 
of security of the system as it just makes it much more difficult for 
the intruder to succeed in his/her attack.

regards,
makan

-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada
*This email does not represent or express the opinions of
Ericsson Inc.
-------------------------------------------------------

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Wed, 01 Oct 2003 12:26:31 +0200, Pavel Machek said:

> > Instead of writing a long detailed explication, I rather give you an 
> > example of how you can use it.
> 
> Can you also add example *why* one would want to use it?
> 
> AFAICS if I want to exec something, I can avoid exec() syscall and do
> mmaps by hand...

The idea isn't to stop you from calling exec*().

The idea is to ensure that if you do execve("/usr/bin/foobar",...) that the
foobar binary hasn't been tampered with and you're not about to launch a binary
differing from what you expected.   Note that on a properly administered
system, this is a *high* level of paranoia, as the file permissions should have
prevented writing to the binary in the first place.  It's also a maintenance
nightmare waiting to happen, as you get to re-sign all the binaries every time
you install a patch, and it won't help prevent trojaned shared libraries...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[viro]

On Wed, Oct 01, 2003 at 09:33:09AM -0400, Makan Pourzandi wrote:
 
> Third, the intruder now has access to the system, he cannot execute the 
> code he brought in with himself (not signed) or he cannot bring it in 
> (c.f. above). So he needs to compile the code on the system. AFAIK, for 
> the absolute majority of servers the admins remove all compilers 
> (specially gcc) on all servers. this is for several different security 
> reasons  (I don't want to get there). therefore, the above hypothesis 
> gets even more difficult to realize. 

Don't be ridiculous.  It's trivial to exploit a local buffer overrun in
one of your signed binaries and have the shellcode mmap the rest.  All
pre-built, of course.

> Last, but I believe the most important, the level of difficulty of 
> execution of such an attack is much higher than the average knowledge 
> level of many script kiddies. The absolute majority of attackers have 
> little or absolutely not any knowledge of the operating systems in 
> general and linux in particular, let aside the knowledge of writing a C 
> program, calling mmaps in that progam and run the malicious code to gain 
> access as root, then remove the module to execute a classical attack.
> 
> There is no such thing as 100% secure system, digsig increases the level 
> of security of the system as it just makes it much more difficult for 
> the intruder to succeed in his/her attack.

Rubbish.  You don't need to compile anything locally and the rest will be
done once by some wanker with half a clue and then repeated by wankers
without a clue (aka script kiddies).

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Makan Pourzandi]

viro@parcelfarce.linux.theplanet.co.uk wrote:

>On Wed, Oct 01, 2003 at 09:33:09AM -0400, Makan Pourzandi wrote:
> 
>  
>
>>Third, the intruder now has access to the system, he cannot execute the 
>>code he brought in with himself (not signed) or he cannot bring it in 
>>(c.f. above). So he needs to compile the code on the system. AFAIK, for 
>>the absolute majority of servers the admins remove all compilers 
>>(specially gcc) on all servers. this is for several different security 
>>reasons  (I don't want to get there). therefore, the above hypothesis 
>>gets even more difficult to realize. 
>>    
>>
>
>Don't be ridiculous.  It's trivial to exploit a local buffer overrun in
>one of your signed binaries and have the shellcode mmap the rest.  All
>pre-built, of course.
>  
>

Hi Viro,

Obviously, I failed to show that the main functionality of digsig is to 
avoid the execution of __normal__ rootkits, Trojan horses and other 
malicious binaries on your system. 

the above was to analyze an imaginary scenario. well, you bring a new 
scenario than the mmap is used from a shell code. well, in this 
scenario, digsig makes it difficult for the intruder to bring his own 
rootkit and run it. i mean, yes he could decide to reboot your system or 
remove all your files or ..., and digsig is not going to help here, it 
isn't its job either !   
Back to the subject, in the first 2 points of my previous email, I tried 
to show that the use of digsig make it difficult for the intruder to 
bring in the malicious binaries, __then and only then__ at last 
resource, to be able to use mmaps, he can choose to compile the code 
locally.  

Once again,  the purpose here is neither to secure system against all 
possible attacks nor to avoid all possible scenarios; digsig is not  
going to avoid you buffer overflows or other vulnerabilities. BTW, there 
are tools to avoid that to happen (c.f. Pax, Exec Shield...).  the 
purpose here is to make it more difficult for the intruder to abuse the 
system. if there is a remote exploit in your system, the intruder can 
use it. however, i believe, as i explained in first 2 points of the 
previous email, digsig  makes it much more difficult for the intruder to 
bring in his rootkit and use it, same for the excution of Trojan horses 
or backdoor programs.

On the other hand, you're right if the people begin to write these 
shellcode mmaps, this is a problem that we have to solve. however, my 
understanding of the state of the art on malware today is that we don't 
have many of these "shellcode mmap" exploits. generally, many of the 
exploits use classical rootkits which still use exec for executing their 
binaries.

regards,
makan

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[viro]

On Wed, Oct 01, 2003 at 02:14:31PM -0400, Makan Pourzandi wrote:
> Hi Viro,
> 
> Obviously, I failed to show that the main functionality of digsig is to 
> avoid the execution of __normal__ rootkits, Trojan horses and other 
> malicious binaries on your system. 

<shrug> so in a month rootkits get updated and we are back to square 1,
with additional mess from patch...

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Willy Tarreau]

Hi Al,

On Wed, Oct 01, 2003 at 07:24:40PM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Oct 01, 2003 at 02:14:31PM -0400, Makan Pourzandi wrote:
> > Hi Viro,
> > 
> > Obviously, I failed to show that the main functionality of digsig is to 
> > avoid the execution of __normal__ rootkits, Trojan horses and other 
> > malicious binaries on your system. 
> 
> <shrug> so in a month rootkits get updated and we are back to square 1,
> with additional mess from patch...

I think that's perfectly true, sadly. It may even become the subject of the
phrack article, next to the collection of insmod_without_module_support, etc...

The only useful feature it would provide would be to secure a system against
people who tamper on the media itself, which is fairly trivial on nfsroot. It
may be interesting to ensure that a server farm which all mount their root from
a central server may not be tricked into executing undesired code injected into
the central NFS server.

The same would be true for removable media such as smartmedia, on PDAs or
specialized systems.

Just a few thoughts,
Willy

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Radu Filip]

On Wed, 1 Oct 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:

> <shrug> so in a month rootkits get updated and we are back to square 1,
> with additional mess from patch...

Viro, I think you have an attitude problem here. "Don't be ridiculous",
"Rubbish", "<shrug>" don't sound very constructive or at least
encouraging.

Over the years it was proved that Linux kernel can be tailored for a very
large number of unexpected and very strange needs. IBM put it into
watches, NASA sent it to space, it is exists in oil wells and so on. I
think that the possibilities offered by Linux kernel are limited only by
the knowledge, imagination and will of every of us. Linux itself was once
a very insignificant and unreliable kernel and many other serious Unix and
Unix-like alternative were available. Still, it is prevailing today because
some peoples believed in what they did.

Especially to your point, should I mention that there are patches that
avoid buffer-overflows? Or that there are patches for gcc that add bound
check to arrays in C?

These peoples are trying to solve a problem. If you have some expertise in
the area of the problem, it might be much useful to come with positive
ideas about how the encountered problems can be solved, instead of
dismissing with so much ease the effort done to solve a real problem.

Come on, I'm sure you can Think Positive (TM).

Regards,

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Pavel Machek]

Hi!

> > <shrug> so in a month rootkits get updated and we are back to square 1,
> > with additional mess from patch...
> 
> Viro, I think you have an attitude problem here. "Don't be ridiculous",
> "Rubbish", "<shrug>" don't sound very constructive or at least
> encouraging.
> 
> Over the years it was proved that Linux kernel can be tailored for a very
> large number of unexpected and very strange needs. IBM put it into
> watches, NASA sent it to space, it is exists in oil wells and so on. I
> think that the possibilities offered by Linux kernel are limited only by
> the knowledge, imagination and will of every of us. Linux itself was once
> a very insignificant and unreliable kernel and many other serious Unix and
> Unix-like alternative were available. Still, it is prevailing today because
> some peoples believed in what they did.
> 
> Especially to your point, should I mention that there are patches that
> avoid buffer-overflows? Or that there are patches for gcc that add bound
> check to arrays in C?

I simply wanted to see valid usage of this. It certainly does not
prevent attacker to get control of your box. Al seems to be right. It
may temporarily redirect script-kiddies, through...

There may be some uses like "prevent tivo users from running their own
software", but I'm not sure I want to encourage some uses. Maybe "its
neccessary to get our phones approved by FCC" would be better.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Larry McVoy]

On Thu, Oct 02, 2003 at 12:55:41AM +0300, Radu Filip wrote:
> Viro, I think you have an attitude problem here. 
[...]
> Come on, I'm sure you can Think Positive (TM).

Al does real work and is about substance, not "Think Positive (TM)"
or any other fad du jour.  I tend to agree with him the most when he is
the most caustic, all he is doing is speaking the truth.  If you can't
handle it, go someplace else.  I *like* what he says because it is true.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signatureverification for binaries

[Edgar Toernig]

Radu Filip wrote:
> 
> Viro, I think you have an attitude problem here. "Don't be ridiculous",
> "Rubbish", "<shrug>" don't sound very constructive or at least
> encouraging.
>[...] 
>
> These peoples are trying to solve a problem.

The "How do I make sure that only licensed software
will run on my new gizmo?" problem?

Why should an open source developer encourage this?

Ciao, ET.

PS: If you really meant security then browse around
and see how the X-Box was hacked...

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[jlnance]

On Wed, Oct 01, 2003 at 04:36:22PM -0700, Larry McVoy wrote:

> or any other fad du jour.  I tend to agree with him the most when he is
> the most caustic, all he is doing is speaking the truth.  If you can't
> handle it, go someplace else.  I *like* what he says because it is true.

At the same time take a look at:

    http://www.bitmover.com/lm/quotes.html

and read the quote about politeness.  It makes a lot of sense, and I was
impressed when I found it the other day.

Thanks,

Jim

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signatureverification for binaries

[David Gordon]

> The "How do I make sure that only licensed software
> will run on my new gizmo?" problem?
> 
> Why should an open source developer encourage this?

Digital signatures in open source software are aimed
at running only allowed (read signed) binaries, the
license question is a side issue. IMHO, this has a
potential to increase the security of a Linux box.

> AFAICS if I want to exec something, I can avoid 
> exec() syscall and do mmaps by hand...
> 				Pavel

That is true. A digital signature will only protect
binary data on hard disk. The whole process from the
hard disk to memory is harder to cover (see
http://www.phrack.org/show.php?p=59&a=5 Short Stories
about execve). I believe that digital signature
verification in the kernel must be placed as close as
possible to the actual mmap of the binary. LSM
framework is the current way of implementing this but
not quite sufficient.

> Don't be ridiculous.  It's trivial to exploit a
local 
> buffer overrun in one of your signed binaries and 
> have the shellcode mmap the rest.  All pre-built, of

> course.

That's also true. A digital signature will not protect
against an already existing vulnerability in a binary
(bo). Let's say for instance that a linux box is
compromised with a bo, usually another backdoor is
created. Even if the system is running Pax (mentioned
by Makan), "http://www.phrack.org/show.php?p=61&a=8
Cerberus Elf interface" describes how to circumvent
this.

But on a system with digitally signed binaries, this
is no longer possible since it requires modification
of the binary which is signed.

My point is that a system with digitally signed
binaries won't prevent existing security holes, but
will prevent the creation of other ones. The attacker
is constrained to use the system as is, ie. to exploit
the same bo. Unless of course the bo gives him access
to the kernel and he disables digital signature
verification.

David



______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

On Thu, 02 Oct 2003 00:55:41 +0300, Radu Filip said:

> Especially to your point, should I mention that there are patches that
> avoid buffer-overflows? Or that there are patches for gcc that add bound
> check to arrays in C?

Hmm.. patches to avoid buffer overflows.. hold that thought.

Also, note that those gcc patches are in general inadequate, in that they
can't do much for the most common case of a bounds-check issue
in C - where a pointer to a char array is passed to another function
which uses it as the target of a strcpy() or such...

(Not to say that the patches are useless - but they're a lot less utility than
sounds at first, precisely because most C code relies so heavily on the
interplay of "array" and "pointer", especially when calling another function)

> These peoples are trying to solve a problem. If you have some expertise in
> the area of the problem, it might be much useful to come with positive
> ideas about how the encountered problems can be solved, instead of
> dismissing with so much ease the effort done to solve a real problem.

(Note that I'm writing this as somebody who is himself running the
exec-shield patches *and* the SELinux stuff and a few other things as
well... so I don't consider this stuff *totally* useless....)

The problem here is that "positive ideas" in this case *DOES* include the
observation that the only thing the patch does is raise the bar on a purely
temporary basis, and that it provides little long-term benefit as soon as the
rootkits start working around it.  As has been pointed out, DigSig only
secures one tiny part of the way that executable code gets into memory.

Yes, it probably does a *very* good job of making sure that the binary
loaded by an exec() call hasn't been tampered with.  On the other hand,
it does *NOTHING* to tamper-proof shared libraries - so if the attacker
had a nice trojan to put into /usr/sbin/pppd and you install DigSig,
all they have to do is wrap a 'if (!strcmp("pppd",argv[0]) {....'
around their code and stick it in /lib/libutil.so instead.  Or drop it into
the PAM directories.  If the attacker could otherwise have modified pppd,
they almost certainly had the ability to modify libutil.so or the PAM stuff
as well.

You're spending a lot of effort solving the problem of making sure that
you can't exec an untrusted binary, when the problem you (presumably)
actually want to solve is making sure that you can't run untrusted code.

Note that Microsoft's literature on their Trusted Computing initiative
seems to indicate that they made this same mistake - they fail to account
for the fact that if you install a Palladium-aware IIS (or whatever), and
then manage to buffer-overflow it, that code will then execute in whatever
context the IIS program has.  As such, it's more about DRM than
about actual security.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature ve rification for binaries

[Makan Pourzandi]

Valdis.Kletnieks@vt.edu wrote:

> On Thu, 02 Oct 2003 00:55:41 +0300, Radu Filip said:
>
>
> Yes, it probably does a *very* good job of making sure that the binary
> loaded by an exec() call hasn't been tampered with.  On the other hand,
> it does *NOTHING* to tamper-proof shared libraries - 
>
I agree, one major improvement would be to extend our work to the shared 
libraries. Quite frankly, I haven't had enough free time to find out how 
to handle this one.  Our first investigations showed that there would be 
no appropraite LSM hook that could handle this. I want to put the 
emphasis on the fact that I didn't spend much time there, so we'll see 
after i spend some days bugging around the code.
 

> You're spending a lot of effort solving the problem of making sure that
> you can't exec an untrusted binary, when the problem you (presumably)
> actually want to solve is making sure that you can't run untrusted code.
>
> Note that Microsoft's literature on their Trusted Computing initiative
> seems to indicate that they made this same mistake - they fail to account
> for the fact that if you install a Palladium-aware IIS (or whatever), and
> then manage to buffer-overflow it, that code will then execute in 
> whatever
> context the IIS program has.  As such, it's more about DRM than
> about actual security.
>
Can you elaborate more in this? I don't agree that what we do has 
something to do with DMR.

I believe there is some misunderstanding, we do not assume that the 
authentication of the binary 
is done by using public keys from big industry names or any, we believe 
that this authentication must be done
using admin's public key (or user's) on the system. and this is how we 
implemented digsig. 
our approach lets free hands to the
admin (or user) to organize the system as he believes to. In our 
approach, the
code is signed by the __admin's__ private key. Then the binary is 
verified by the public key introduced by the __admin__. This means
that you could always sign __all__ binaries you wanr on your system with 
your own keys and have absolutely no problem running them. The only 
thing Digsig garantees you is that if __you__ signed a binary, nobody 
else than you (or people that you allowed) can change that binary and 
run it in your system. But nobody can forbid __you__ from running the 
binary. I see that we give more power to the admin (or user) over how 
s/he wants his system to run rather than enforcing any DMR alike 
approach. digsig approach is based on __locally__ signing all binaries, 
we don't support any kind of signature verificatin from binaries coming 
from outside (our documentation is not yet there but see bsign's 
docuementation for more details)

To simplify things, our approach is much closer to Tripwire than any 
kind of DMR alike that I heard of; AFAIK, Tripwire allows you to sign 
your files and check their integrity upon the time. to over simplify, 
this is somehow what we do but for binaries only and at run-time.
btw, even to simplify more, isn't that similar to what we do when we 
accept to verify the md5 or signature of a rpm which we download from 
red hat?

regards,
makan
 
-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada
*This email does not represent or express the opinions of
Ericsson Inc.
-------------------------------------------------------