[ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Makan Pourzandi]

Hi,

Digsig development team would like to announce the release 1.5 of digsig.

This kernel module helps system administrators control Executable and 
Linkable Format (ELF) binary execution and library loading based on
the presence of a valid digital signature.  The main functionality is
to help system administrators distinguish applications he/she trusts
(and therefore signs) from viruses, worms (and other nuisances). It is
based on the Linux Security Module hooks.

The code is GPL and available from:
http://sourceforge.net/projects/disec/, download digsig-1.5. For
more documentation, please refer to disec.sourcefrge.net.

We hope that it'll be useful to you.

All bug reports and feature requests or general feedback are welcome
(please CC me and disec-devel@lists.sourceforge.net in your answer or 
feedback to the mailing list).

Regards,
Makan Pourzandi

-- 

Makan Pourzandi, Open Systems Lab
Ericsson Research, Montreal, Canada
*This email does not represent or express the opinions of Ericsson Inc.*

Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Stephen Smalley]

On Fri, 2006-04-21 at 09:56 +0000, Makan Pourzandi wrote:
> Hi,
> 
> Digsig development team would like to announce the release 1.5 of digsig.
> 
> This kernel module helps system administrators control Executable and 
> Linkable Format (ELF) binary execution and library loading based on
> the presence of a valid digital signature.  The main functionality is
> to help system administrators distinguish applications he/she trusts
> (and therefore signs) from viruses, worms (and other nuisances). It is
> based on the Linux Security Module hooks.
> 
> The code is GPL and available from:
> http://sourceforge.net/projects/disec/, download digsig-1.5. For
> more documentation, please refer to disec.sourcefrge.net.
> 
> We hope that it'll be useful to you.
> 
> All bug reports and feature requests or general feedback are welcome
> (please CC me and disec-devel@lists.sourceforge.net in your answer or 
> feedback to the mailing list).

That URL doesn't seem to be working at present.
You should submit your security module for mainline; otherwise, LSM
might be removed.  See
http://marc.theaimsgroup.com/?l=linux-security-module&m=114530167302454&w=2

Also discussed on lwn.net.

-- 
Stephen Smalley
National Security Agency

RE: [Disec-devel] Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Axelle Apvrille]

> That URL doesn't seem to be working at present.

Probably a temporary outage ? anyway, it's working
now...

http://sourceforge.net/projects/disec/
or http://disec.sourceforge.net/

both work.

Regards,
Axelle.



	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. 
Rendez-vous sur http://fr.yahoo.com/set

RE: [Disec-devel] Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Stephen Smalley]

On Fri, 2006-04-21 at 18:13 +0200, Axelle Apvrille wrote:
> > That URL doesn't seem to be working at present.
> 
> Probably a temporary outage ? anyway, it's working
> now...
> 
> http://sourceforge.net/projects/disec/
> or http://disec.sourceforge.net/
> 
> both work.

Yes, seems to be up now.  But you do need to submit your module if you
want to make a case that LSM should be retained in mainline.  Even if
LSM stays, it could be altered in the future to help counter misuse of
the interface, and such changes could break your module if you aren't in
the tree.  Not to mention that out-of-tree modules don't fair well in
general.

-- 
Stephen Smalley
National Security Agency

Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Arjan van de Ven]

On Fri, 2006-04-21 at 09:56 +0000, Makan Pourzandi wrote:
> Hi,
> 
> Digsig development team would like to announce the release 1.5 of digsig.
> 
> This kernel module helps system administrators control Executable and 
> Linkable Format (ELF) binary execution and library loading based on
> the presence of a valid digital signature.  The main functionality is
> to help system administrators distinguish applications he/she trusts
> (and therefore signs) from viruses, worms (and other nuisances). It is
> based on the Linux Security Module hooks.

does this also prevent people writing their own elf loader in a bit of
perl and just mmap the code ?

Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Ulrich Drepper]

On 4/23/06, Arjan van de Ven <arjan@infradead.org> wrote:
> does this also prevent people writing their own elf loader in a bit of
> perl and just mmap the code ?

You will never get 100% protection from a mechanism like signed
binaries.  What you can get in collaboration with other protections
like SELinux is another layer of security.  That's good IMO.  Not
being able to slide in modified and substituted binaries which then
would be marked to get certain privileges is a plus.

But preventing every type of code loading or generation at userlevel
cannot be prevented this way.  Just look at the code proposed to deal
with execmem problems in
http://people.redhat.com/drepper/selinux-mem.html.  This is with all
the SELinux mechanisms in place and activated.  You can prevent by
using the noexec mount option for every writable filesystem. But this
is so far not possible for ordinary machines.  There are widely used
programs out there which need to dynamically generate code.

Signed binaries are therefore a complete solution only for a very
limited number of situation.  For embedded systems I see this but here
we also have the "Tivo problem" where devices are built on top of
Linux and people are still prevented from extending/modifying them. 
Beside that there is potentially some locked down machines with
limited functionality which can use it (e.g., DMZ servers, but they
mustn't use Java etc).

So, I do not think that signed binaries have a big upside.  And they
have a potential big downside.  The better approach to ensure that
SELinux, for instance, doesn't change the labels for incorrect
binaries is to integrate restorecon etc with the package manager and
have functionality in the package manager to recognize incorrect
binaries.  This might again mean signed binaries although I imagine
the current signed hash values work fine, too.  Although we might want
to go from MD5 to SHA256.

I have been working on signed binaries at some point myself but
abandoned it after realizing that it realistically only can be
misused.  If I'd have a vote I'd keep this stuff out of the kernel.

Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Nix]

On 23 Apr 2006, Ulrich Drepper prattled cheerily:
> On 4/23/06, Arjan van de Ven <arjan@infradead.org> wrote:
>> does this also prevent people writing their own elf loader in a bit of
>> perl and just mmap the code ?
> 
> You will never get 100% protection from a mechanism like signed
> binaries.  What you can get in collaboration with other protections
> like SELinux is another layer of security.  That's good IMO.  Not
> being able to slide in modified and substituted binaries which then
> would be marked to get certain privileges is a plus.

Of course in order to use it in conjunction with SELinux right now you
need LSM stacking, which is a nest of dragons in itself (if not used
very carefully stacking can weaken security rather than strengthening
it...)

> But preventing every type of code loading or generation at userlevel
> cannot be prevented this way.

Oh, indeed not. It's just a stopgap that blocks some (large) percentage
of script kiddy attacks that involve downloading binaries and then
executing them, or even compiling them on the spot (not that those are
as common these days).

> http://people.redhat.com/drepper/selinux-mem.html.  This is with all
> the SELinux mechanisms in place and activated.  You can prevent by
> using the noexec mount option for every writable filesystem. But this
> is so far not possible for ordinary machines.  There are widely used
> programs out there which need to dynamically generate code.

Yeah. I'll admit I've found signed binaries principally useful on
stripped-down firewalls and firewall UML instances. These boxes don't
tend to run, say, CLISP or SBCL or OpenOffice (at least if they do the
firewall maintainer needs shooting).

> Signed binaries are therefore a complete solution only for a very
> limited number of situation.

`Stripped-down firewalls' on its own is a big niche.

Combine it with SELinux, exec-shield, FORTIFY_SOURCE, -fstack-protector
and, say, a COWed filesystem read off a CD and reset with every boot,
and you start to get a bit less insecure than you would otherwise be.

>                              For embedded systems I see this but here
> we also have the "Tivo problem" where devices are built on top of
> Linux and people are still prevented from extending/modifying them. 

Yeah, that's nasty: but the inverse face is that, for instance, nobody
can compile a new binary on my firewall without access to a private key
kept on a CD which is not normally in the drive. Replace `not in the
drive' with `at a manufacturer's site locked securely away from the
user' and suddenly this security benefit becomes an attack on
freedom. But that doesn't mean that there's anything wrong with it *as a
security benefit*: I haven't tivoized myself entirely *because* I have
access to that key, but there's no way any software can possibly tell
that.

> Beside that there is potentially some locked down machines with
> limited functionality which can use it (e.g., DMZ servers, but they
> mustn't use Java etc).

Yes indeed.

> So, I do not think that signed binaries have a big upside.  And they
> have a potential big downside.

It's another hurdle for the bad guys to leap, and many will fall at the
wayside.

> I have been working on signed binaries at some point myself but
> abandoned it after realizing that it realistically only can be
> misused.  If I'd have a vote I'd keep this stuff out of the kernel.

Well, I'm using it, but I'd agree that the potential for misuse by the
tivos of this world is high. I don't know if it should go into mainline,
but let's not make it intentionally hard for it to exist
out-of-tree. It's useful to help professional paranoids sleep at
night. :)

(But, well, since the code *exists*, the tivos of this world can
*already* tivoize. I can't see what keeping it out would do, really.
I suppose it would increase the barrier for a would-be tivoizer.)

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva

Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Serge E. Hallyn]

Quoting Nix (nix@esperi.org.uk):
> On 23 Apr 2006, Ulrich Drepper prattled cheerily:
> > On 4/23/06, Arjan van de Ven <arjan@infradead.org> wrote:
> >> does this also prevent people writing their own elf loader in a bit of
> >> perl and just mmap the code ?
> > 
> > You will never get 100% protection from a mechanism like signed
> > binaries.  What you can get in collaboration with other protections
> > like SELinux is another layer of security.  That's good IMO.  Not
> > being able to slide in modified and substituted binaries which then
> > would be marked to get certain privileges is a plus.
> 
> Of course in order to use it in conjunction with SELinux right now you
> need LSM stacking, which is a nest of dragons in itself (if not used
> very carefully stacking can weaken security rather than strengthening
> it...)

Perhaps.  On the other hand, combining selinux with digsig you get:

	1. selinux integrity controls on crucial digsig files, which
	digsig does not (and should not) protect itself
	2. digsig controls over selinux entry types.  So now you can
	protect domain transitions with small, verifiable entry points
	which are then signed to boot.

> `Stripped-down firewalls' on its own is a big niche.

Every home should have one.

> Combine it with SELinux, exec-shield, FORTIFY_SOURCE, -fstack-protector
> and, say, a COWed filesystem read off a CD and reset with every boot,
> and you start to get a bit less insecure than you would otherwise be.

Sounds like a good basis for a new tiny distro.

-serge

Re: [ANNOUNCE] Release Digsig 1.5: kernel module for run-time authentication of binaries

[Ulrich Drepper]

On 4/24/06, Nix <nix@esperi.org.uk> wrote:
> > But preventing every type of code loading or generation at userlevel
> > cannot be prevented this way.
>
> Oh, indeed not. It's just a stopgap that blocks some (large) percentage
> of script kiddy attacks that involve downloading binaries and then
> executing them, or even compiling them on the spot (not that those are
> as common these days).

Script kiddies don't write the exploit code themselves.  And for those
who write the code it is no problem to circumvent the signature
testing.


> Yeah. I'll admit I've found signed binaries principally useful on
> stripped-down firewalls and firewall UML instances. These boxes don't
> tend to run, say, CLISP or SBCL or OpenOffice (at least if they do the
> firewall maintainer needs shooting).

But they have Perl, Python, etc.  Those are sufficient.  Heck, I can
cause havor with bash.


> Combine it with SELinux, exec-shield, FORTIFY_SOURCE, -fstack-protector
> and, say, a COWed filesystem read off a CD and reset with every boot,
> and you start to get a bit less insecure than you would otherwise be.

Take signed binaries off of this list and you don't lose anything.


> It's another hurdle for the bad guys to leap, and many will fall at the
> wayside.

It is a little one-time effort.  This approach differs in that it
simply shifts the way binaries are introduced.  I can write a dynamic
loader in Perl.  and after that I don't load ELF binaries through the
kernel ever again.  If such a loader doesn't exist today it could very
well exist in a few months and after that this "protection" is
completely useless.  Every script kiddy will have it.

This is the big difference to techniques like randomization which
might be circumventent with a certain probability but never fully can
be removed.  Stacking those kind of protections is a good idea
because, if they are not fully correlated, the stacking provides
additional protection.  Signed binaries do not.