RE: [ANNOUNCE] Release Digsig 1.5: kernel module for run-timeauthentication of binaries

RE: [ANNOUNCE] Release Digsig 1.5: kernel module for run-timeauthentication of binaries

[Makan Pourzandi (QB/EMC)]

Hi Arjan, 

I hope I correctly understood your question, DigSig uses LSM hooks to
check the digital signature before loading it, then as long as your elf
loader uses kernel system calls, it's covered by DigSig. 

Regards 
Makan 


> -----Original Message-----
> From: linux-security-module-owner@vger.kernel.org 
> [mailto:linux-security-module-owner@vger.kernel.org] On 
> Behalf Of Arjan van de Ven
> Sent: April 23, 2006 8:19 AM
> To: Makan Pourzandi (QB/EMC)
> Cc: linux-kernel@vger.kernel.org; 
> linux-security-module@vger.kernel.org; Serue Hallyen; Axelle 
> Apvrille; 'disec-devel@lists.sourceforge.net'
> Subject: Re: [ANNOUNCE] Release Digsig 1.5: kernel module for 
> run-timeauthentication of binaries
> 
> 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 ?
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

RE: [ANNOUNCE] Release Digsig 1.5: kernel module for run-timeauthentication of binaries

[Arjan van de Ven]

On Mon, 2006-04-24 at 12:27 -0400, Makan Pourzandi (QB/EMC) wrote:
> Hi Arjan, 
> 
> I hope I correctly understood your question, DigSig uses LSM hooks to
> check the digital signature before loading it, then as long as your elf
> loader uses kernel system calls, it's covered by DigSig. 

ok I have to admit that this answer worries me.

how can it be covered? How do you distinguish an elf loader application
(which just uses open + mmap after all) with... say a grep-calling perl
script?

As long as you allow apps to mmap (or even just read() a file into
memory).... they can start acting like an elf loader if they chose to do
so. And.. remember it's not the files WITH signature you're protecting
against (which you could check) but the ones WITHOUT. And there are many
of those; and you can't sign ALL files I think, not without going
through really great hoops anyway.

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

[Nix]

On 24 Apr 2006, Arjan van de Ven announced authoritatively:
> On Mon, 2006-04-24 at 12:27 -0400, Makan Pourzandi (QB/EMC) wrote:
>> Hi Arjan, 
>> 
>> I hope I correctly understood your question, DigSig uses LSM hooks to
>> check the digital signature before loading it, then as long as your elf
>> loader uses kernel system calls, it's covered by DigSig. 
> 
> ok I have to admit that this answer worries me.
> 
> how can it be covered? How do you distinguish an elf loader application
> (which just uses open + mmap after all) with... say a grep-calling perl
> script?

It checks mmap and mprotect with PROT_EXEC, and execve().

> As long as you allow apps to mmap (or even just read() a file into
> memory).... they can start acting like an elf loader if they chose to do
> so. And.. remember it's not the files WITH signature you're protecting
> against (which you could check) but the ones WITHOUT. And there are many
> of those; and you can't sign ALL files I think, not without going
> through really great hoops anyway.

Why not? It's one command with bsign:

bsign -s -I -i / -e /proc

will sign every ELF shared object and executable on the system.

-- 
`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-timeauthentication of binaries

[Arjan van de Ven]

On Mon, 2006-04-24 at 21:32 +0100, Nix wrote:
> On 24 Apr 2006, Arjan van de Ven announced authoritatively:
> > On Mon, 2006-04-24 at 12:27 -0400, Makan Pourzandi (QB/EMC) wrote:
> >> Hi Arjan, 
> >> 
> >> I hope I correctly understood your question, DigSig uses LSM hooks to
> >> check the digital signature before loading it, then as long as your elf
> >> loader uses kernel system calls, it's covered by DigSig. 
> > 
> > ok I have to admit that this answer worries me.
> > 
> > how can it be covered? How do you distinguish an elf loader application
> > (which just uses open + mmap after all) with... say a grep-calling perl
> > script?
> 
> It checks mmap and mprotect with PROT_EXEC, and execve().

so no jvm's or flash plugins.

and the stack can be executable if the app wants it to be as well...
so it's not all that easy as you make it sound

> will sign every ELF shared object and executable on the system.

but it won't sign the not-really-elf-but-virus-anyway files. 

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

[Nix]

On Mon, 24 Apr 2006, Arjan van de Ven yowled:
> On Mon, 2006-04-24 at 21:32 +0100, Nix wrote:
>> It checks mmap and mprotect with PROT_EXEC, and execve().
> 
> so no jvm's or flash plugins.

Well, you'll have to sign the flash plugin. This isn't
sign-at-compilation-time; bsign can sign just about anything (although I
guess the Mozilla security shared library, which is itself signed by a
different tool, might pose an interesting conundrum).

> and the stack can be executable if the app wants it to be as well...

Well, yes, but if the app isn't signed the attacker can't run it.
Obviously digsig doesn't close all avenues of attack: you'd use
exec-shield or something of the kind to block off the executable-stack
thing from the majority of apps (and yes, if you flip PT_GNU_STACK you
should resign the app, IIRC).

> so it's not all that easy as you make it sound

Everyone seems to want the One Security Fix To Rule Them All. This
isn't it: it's just one of a myriad of barriers to throw in the
bad guys' way. None of them stop everyone: most of them should
stop most of them.

I'm not trying to keep governments out. If they want in, they'll
*get* in, if need be by breaking in and physically removing the
machine...

>> will sign every ELF shared object and executable on the system.
> 
> but it won't sign the not-really-elf-but-virus-anyway files. 

The idea is that you don't *have* them on there when you do the
initial signing round, and that after that you only sign the
stuff you install yourself (and, of course, that you don't keep
the key on the same machine, or even accessible without physical
actions, I'd hope: that's why I keep mine on a CD-ROM physically
removed from the drive when not signing).

-- 
`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-timeauthentication of binaries

[Arjan van de Ven]

On Tue, 2006-04-25 at 00:35 +0100, Nix wrote:
> On Mon, 24 Apr 2006, Arjan van de Ven yowled:
> > On Mon, 2006-04-24 at 21:32 +0100, Nix wrote:
> >> It checks mmap and mprotect with PROT_EXEC, and execve().
> > 
> > so no jvm's or flash plugins.
> 
> Well, you'll have to sign the flash plugin. This isn't
> sign-at-compilation-time; 

the point I made is that a jvm has executable memory capabilities (it
has to) and can be made an elf loader. At which point.. game over.



> > so it's not all that easy as you make it sound
> 
> Everyone seems to want the One Security Fix To Rule Them All. 

I'm not part of that "everyone". I'm all in favor of removing degrees of
freedom. However this one doesn't, it's just pure fake. This is similar
to posting a sign at your unlocked front door "please don't burgle me
via my front door" while your windows are also open.

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

[Nix]

On Tue, 25 Apr 2006, Arjan van de Ven prattled cheerily:
> On Tue, 2006-04-25 at 00:35 +0100, Nix wrote:
>> On Mon, 24 Apr 2006, Arjan van de Ven yowled:
>> > On Mon, 2006-04-24 at 21:32 +0100, Nix wrote:
>> >> It checks mmap and mprotect with PROT_EXEC, and execve().
>> > 
>> > so no jvm's or flash plugins.
>> 
>> Well, you'll have to sign the flash plugin. This isn't
>> sign-at-compilation-time; 
> 
> the point I made is that a jvm has executable memory capabilities (it
> has to) and can be made an elf loader. At which point.. game over.

Yeah, you'd have to avoid allowing hostile ELF loaders to execute, but
even they are impeded somewhat: they can't use PROT_EXEC mappings but
have to e.g. use an executable stack hack.

To mix a metaphor badly, it raises the bar; it doesn't burn down the
gym.

>> > so it's not all that easy as you make it sound
>> 
>> Everyone seems to want the One Security Fix To Rule Them All. 
> 
> I'm not part of that "everyone". I'm all in favor of removing degrees of
> freedom. However this one doesn't, it's just pure fake. This is similar
> to posting a sign at your unlocked front door "please don't burgle me
> via my front door" while your windows are also open.

The JVM example is a bit nasty, I'll admit. (Of course I'm safe because
my stripped-down firewall only includes one interpreter, perl, and
that's executable by root only. ;) )

-- 
`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-timeauthentication of binaries

[Geert Uytterhoeven]

On Tue, 25 Apr 2006, Arjan van de Ven wrote:
> On Tue, 2006-04-25 at 00:35 +0100, Nix wrote:
> > On Mon, 24 Apr 2006, Arjan van de Ven yowled:
> > > On Mon, 2006-04-24 at 21:32 +0100, Nix wrote:
> > >> It checks mmap and mprotect with PROT_EXEC, and execve().
> > > 
> > > so no jvm's or flash plugins.
> > 
> > Well, you'll have to sign the flash plugin. This isn't
> > sign-at-compilation-time; 
> 
> the point I made is that a jvm has executable memory capabilities (it
> has to) and can be made an elf loader. At which point.. game over.

Then don't sign the jvm ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

[Axelle Apvrille]

Hi all,

Just my few cents on signed binaries and DigSig. It's
kind of a very partial reply to several parts of
various emails (Arjan, Ulrich, Nix ...), sorry for
that ;-)

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

I'm not sure to exactly understand what you mean:

- if you mean writing an application able to read &
'interpret' an ELF executable: again, I think DigSig
will prevent this, because when you mmap the code,
this calls (at kernel level) do_mmap which triggers an
LSM hook called file_mmap. And we implement checks in
that hook...

- if you mean modifying the ELF loader so that do_mmap
/ file_mmap aren't called, well you'll need to hack
the kernel, won't you ?

- finally, note you also have choice not to sign this
elf loader of yours. If it isn't signed, it won't ever
run ;-)

2- "You will never get 100% protection from a
mechanism like signed binaries"

Sure. I entirely agree though, if we're honest, *no*
system is ever a 100 % protection ;-)
I think our paper (http://disec.sourceforge.net/ or
http://www.usenix.org/events/lisa04/tech/apvrille.html)
is clear about what we mean to protect and what we do
not, and IMHO, 
in security, we cannot expect more of any system.

3- "I've found signed binaries principally useful on
stripped-down firewalls and firewall UML instances"

Indeed. I foresee use of DigSig for hosts that are not
meant to change 'too' often (for example, not
a developer or a user desktop - although I do
personnally have DigSig on mine ;-)) ). Stripped-down
servers or firewalls are good example (and they do
indeed represent a big niche). BTW, I also
foresee use of DigSig in small embedded systems, and
actually, in that area, I heard of Umbrella,
an open source project using DigSig (I don't know the
status).


Hope this helps !
Best regards,

Axelle.
DigSig - http://disec.sourceforge.net


	
	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger. Appelez le monde entier à partir de 0,012 €/minute ! 
Téléchargez sur http://fr.messenger.yahoo.com

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

[Arjan van de Ven]

On Tue, 2006-04-25 at 18:11 +0200, Axelle Apvrille wrote:
> Hi all,
> 
> Just my few cents on signed binaries and DigSig. It's
> kind of a very partial reply to several parts of
> various emails (Arjan, Ulrich, Nix ...), sorry for
> that ;-)
> 
> 1- "does this also prevent people writing their own
> elf loader in a bit of perl and just mmap the code"
> 
> I'm not sure to exactly understand what you mean:
> 
> - if you mean writing an application able to read &
> 'interpret' an ELF executable: again, I think DigSig
> will prevent this, because when you mmap the code,
> this calls (at kernel level) do_mmap which triggers an
> LSM hook called file_mmap. And we implement checks in
> that hook...

this is not correct, you don't need mmap you can do a read just fine as
well.


> - finally, note you also have choice not to sign this
> elf loader of yours. If it isn't signed, it won't ever
> run ;-)

so you didn't sign perl ? or bash ?

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

[Nix]

On Tue, 25 Apr 2006, Arjan van de Ven said:
> On Tue, 2006-04-25 at 18:11 +0200, Axelle Apvrille wrote:
>> - finally, note you also have choice not to sign this
>> elf loader of yours. If it isn't signed, it won't ever
>> run ;-)
> 
> so you didn't sign perl ? or bash ?

You can write an elf loader in bash?!

(If you have, well, wow, can I see it? It sounds like an incredibly
nifty hack. Nearly useless, of course, but incredibly nifty.)

-- 
`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-timeauthentication of binaries

[Chris Boot]

On 25 Apr 2006, at 17:11, Axelle Apvrille wrote:

> - finally, note you also have choice not to sign this
> elf loader of yours. If it isn't signed, it won't ever
> run ;-)

Wouldn't you need to sign, say, /lib/ld-linux.so? In that case, you  
can simply get it to load an execute almost anything that's ELF, even  
on filesystems marked noexec, if I'm not mistaken...

Chris

-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

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

[Valdis.Kletnieks]

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

On Tue, 25 Apr 2006 20:01:24 BST, Chris Boot said:

> Wouldn't you need to sign, say, /lib/ld-linux.so? In that case, you  
> can simply get it to load an execute almost anything that's ELF, even  
> on filesystems marked noexec, if I'm not mistaken...

2.6.0 included a fix to stop that from working from noexec filesystems.

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

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

[Arjan van de Ven]

On Tue, 2006-04-25 at 19:57 +0100, Nix wrote:
> On Tue, 25 Apr 2006, Arjan van de Ven said:
> > On Tue, 2006-04-25 at 18:11 +0200, Axelle Apvrille wrote:
> >> - finally, note you also have choice not to sign this
> >> elf loader of yours. If it isn't signed, it won't ever
> >> run ;-)
> > 
> > so you didn't sign perl ? or bash ?
> 
> You can write an elf loader in bash?!

I've not tried it.. but afaics bash scripts are sufficiently turing
complete to pull it off ;)

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

[Valdis.Kletnieks]

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

On Tue, 25 Apr 2006 21:37:48 +0200, Arjan van de Ven said:
> On Tue, 2006-04-25 at 19:57 +0100, Nix wrote:
> > On Tue, 25 Apr 2006, Arjan van de Ven said:
> > > On Tue, 2006-04-25 at 18:11 +0200, Axelle Apvrille wrote:
> > >> - finally, note you also have choice not to sign this
> > >> elf loader of yours. If it isn't signed, it won't ever
> > >> run ;-)
> > > 
> > > so you didn't sign perl ? or bash ?
> > 
> > You can write an elf loader in bash?!
> 
> I've not tried it.. but afaics bash scripts are sufficiently turing
> complete to pull it off ;)

Well, somebody did 'shasm' (an assembler in bash), so I don't see any reason
you can't do an elf loader... (OK, so you *might* have to write a machine
emulator in bash, store the binary in an array, and emulate the sucker...)

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

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

[Serge E. Hallyn]

Quoting Chris Boot (bootc@bootc.net):
> On 25 Apr 2006, at 17:11, Axelle Apvrille wrote:
> 
> >- finally, note you also have choice not to sign this
> >elf loader of yours. If it isn't signed, it won't ever
> >run ;-)
> 
> Wouldn't you need to sign, say, /lib/ld-linux.so?  In that case, you  
> can simply get it to load an execute almost anything that's ELF, even  

It uses dlopen, which does mmap(PROT_EXEC), at which point digsig will
check for a signature.

If you rewrite it to not use mmap(PROT_EXEC), then the signature will
not match.  If you resign it, then you presumably know what you're
doing.

I don't see the problem in this case.

> on filesystems marked noexec, if I'm not mistaken...

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

[Kyle Moffett]

On Apr 25, 2006, at 15:52:45, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 25 Apr 2006 21:37:48 +0200, Arjan van de Ven said:
>> On Tue, 2006-04-25 at 19:57 +0100, Nix wrote:
>>> On Tue, 25 Apr 2006, Arjan van de Ven said:
>>>> so you didn't sign perl ? or bash ?
>>>
>>> You can write an elf loader in bash?!
>>
>> I've not tried it.. but afaics bash scripts are sufficiently  
>> turing complete to pull it off ;)
>
> Well, somebody did 'shasm' (an assembler in bash), so I don't see  
> any reason you can't do an elf loader... (OK, so you *might* have  
> to write a machine emulator in bash, store the binary in an array,  
> and emulate the sucker...)

Well I know that there are ways in Perl to overwrite arbitrary memory  
(it's considered a bug of a certain XS library, although it has no  
security implications because you could do the equivalent in Perl  
anyways).  I would assume that it's quite possible to do the same in  
bash with a specially formatted bash script.  Once you can scribble  
on arbitrary memory, you can load a compiled ELF loader and execute  
it without much trouble at all.  A signed perl binary would open a  
hole the size of a barn door in your scheme, I think.

Cheers,
Kyle Moffett

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

[Ulrich Drepper]

On 4/25/06, Axelle Apvrille <axelle_apvrille@yahoo.fr> wrote:
> 1- "does this also prevent people writing their own
> elf loader in a bit of perl and just mmap the code"
>
> I'm not sure to exactly understand what you mean:
>
> - if you mean writing an application able to read &
> 'interpret' an ELF executable: again, I think DigSig
> will prevent this, because when you mmap the code,
> this calls (at kernel level) do_mmap which triggers an
> LSM hook called file_mmap. And we implement checks in
> that hook...
>
> - if you mean modifying the ELF loader so that do_mmap
> / file_mmap aren't called, well you'll need to hack
> the kernel, won't you ?
>
> - finally, note you also have choice not to sign this
> elf loader of yours. If it isn't signed, it won't ever
> run ;-)

No, there no problem writing a loader.  All you need is to create
anonymous mappings.  Via mmap, maybe on the stack, some heaps are
still executable.  Then you load the code, fix it up for the address,
and be done.  The kernel cannot and will not prevent a read(2) call on
the binary.  That's all that's needed.  And without the SELinux
support in place you cannot prevent non-exec memory creation and even
then, some people need it (jvms, OpenGL libs, etc) to generate code on
the fly.  So it's never completely ruled out.  Again, look at the code
in http://people.redhat.com/drepper/selinux-mem.html.

Given you have executable anonymous memory it is a one-time small
effort to write a loader and you're done.  Nothing your signature
detection code can do about it.  This is snake oil.

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

[Serge E. Hallyn]

Quoting Ulrich Drepper (drepper@gmail.com):
> On 4/25/06, Axelle Apvrille <axelle_apvrille@yahoo.fr> wrote:
> >1- "does this also prevent people writing their own
> >elf loader in a bit of perl and just mmap the code"
> >
> >I'm not sure to exactly understand what you mean:
> >
> >- if you mean writing an application able to read &
> >'interpret' an ELF executable: again, I think DigSig
> >will prevent this, because when you mmap the code,
> >this calls (at kernel level) do_mmap which triggers an
> >LSM hook called file_mmap. And we implement checks in
> >that hook...
> >
> >- if you mean modifying the ELF loader so that do_mmap
> >/ file_mmap aren't called, well you'll need to hack
> >the kernel, won't you ?
> >
> >- finally, note you also have choice not to sign this
> >elf loader of yours. If it isn't signed, it won't ever
> >run ;-)
> 
> No, there no problem writing a loader.  All you need is to create
> anonymous mappings.  Via mmap, maybe on the stack, some heaps are
> still executable.  Then you load the code, fix it up for the address,
> and be done.  The kernel cannot and will not prevent a read(2) call on
> the binary.  That's all that's needed.  And without the SELinux
> support in place you cannot prevent non-exec memory creation and even

BS - you can stack another LSM to prevent that.

Or, stack it with SELinux.  I've tested that combination before with no
problems.

> then, some people need it (jvms, OpenGL libs, etc) to generate code on
> the fly.  So it's never completely ruled out.  Again, look at the code
> in http://people.redhat.com/drepper/selinux-mem.html.
> 
> Given you have executable anonymous memory it is a one-time small
> effort to write a loader and you're done.  Nothing your signature

A one time effort to write it *and sign it*.

You could just as well write it and give it it's own domain with {
execheap execmem execstack execmod } permissions.

> detection code can do about it.  This is snake oil.

-serge

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

[Arjan van de Ven]

> A one time effort to write it *and sign it*.
you don't sign nor need to sign perl or bash scripts. Why would a loader
be written in ELF itself? There's absolutely no reason for that.

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

[Serge E. Hallyn]

Quoting Arjan van de Ven (arjan@infradead.org):
> 
> > A one time effort to write it *and sign it*.
> you don't sign nor need to sign perl or bash scripts. Why would a loader
> be written in ELF itself? There's absolutely no reason for that.

Yup, that's an unfortunate shortcoming.  We'd been wanting to re-post to
lkml for a long time to get ideas to fix that.

I had an extension to digsig earlier which enabled signing shellscripts
using xattrs (just because it was a trivial task), but that's clearly
insufficient as it would catch "./myscript.pl" but not "perl
myscript.pl".

For now obviously the only thing to do is make sure that sensitive
accounts (i.e. accounts not severely restricted through selinux) can't
use anything but, say, rsh.  I assume this is what previous posters
using digsig do?

Anyone have any better ideas for properly handling shellscripts?

-serge

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

[Arjan van de Ven]

On Fri, 2006-04-28 at 11:29 -0500, Serge E. Hallyn wrote:
> Quoting Arjan van de Ven (arjan@infradead.org):
> > 
> > > A one time effort to write it *and sign it*.
> > you don't sign nor need to sign perl or bash scripts. Why would a loader
> > be written in ELF itself? There's absolutely no reason for that.
> 
> Yup, that's an unfortunate shortcoming.  We'd been wanting to re-post to
> lkml for a long time to get ideas to fix that.
> 
> I had an extension to digsig earlier which enabled signing shellscripts
> using xattrs (just because it was a trivial task), but that's clearly
> insufficient as it would catch "./myscript.pl" but not "perl
> myscript.pl".


there is a worse one:

perl < somefile

or

wget -O - <url> | perl

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

[Christoph Hellwig]

On Fri, Apr 28, 2006 at 11:09:14AM -0500, Serge E. Hallyn wrote:
> BS - you can stack another LSM to prevent that.
> 
> Or, stack it with SELinux.  I've tested that combination before with no
> problems.

The real question here is why use lsm at all?  lsm sounds like the wrong
set of hooks for something like this.  If you look at the hooks they are
clearly for access control handling, which this isn't at all.  I bet
your code would be a lot simpler if you just hooked into the right places
directly.  and made it controllable by selinux or $lsm.

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

[Serge E. Hallyn]

Quoting Christoph Hellwig (hch@infradead.org):
> On Fri, Apr 28, 2006 at 11:09:14AM -0500, Serge E. Hallyn wrote:
> > BS - you can stack another LSM to prevent that.
> > 
> > Or, stack it with SELinux.  I've tested that combination before with no
> > problems.
> 
> The real question here is why use lsm at all?  lsm sounds like the wrong
> set of hooks for something like this.  If you look at the hooks they are
> clearly for access control handling, which this isn't at all.  I bet
> your code would be a lot simpler if you just hooked into the right places
> directly.  and made it controllable by selinux or $lsm.

The evm code (which should be released soon) introduces an integrity
subsystem, using TPM.  The crypto part of digsig could become another
user of that subsystem.

At that point like you say selinux could mark types which can cause
domain transitions as needing to be signed, and, if lsm's not dead,
other lsm's could use it other ways if they like.

thanks,
-serge

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

[Michael Tokarev]

Serge E. Hallyn wrote:
> Quoting Arjan van de Ven (arjan@infradead.org):
>>> A one time effort to write it *and sign it*.
>> you don't sign nor need to sign perl or bash scripts. Why would a loader
>> be written in ELF itself? There's absolutely no reason for that.
> 
> Yup, that's an unfortunate shortcoming.  We'd been wanting to re-post to
> lkml for a long time to get ideas to fix that.
> 
> I had an extension to digsig earlier which enabled signing shellscripts
> using xattrs (just because it was a trivial task), but that's clearly
> insufficient as it would catch "./myscript.pl" but not "perl
> myscript.pl".

Another thing to do is to modify perl to verify signatures of
the scripts it's executing, sign *that* perl binary, and disallow
executing of unsigned perl scripts...

/mjt, who's joking only partially.