headers
Jan Schaumann | 23 Sep 2010 04:22
Favicon
Gravatar

execution policy for shells

Hello,

I just stumbled upon this:
http://technet.microsoft.com/en-us/library/dd347628.aspx

Apparently, Microsoft's Powershell has the concept of an Execution
Policy specifying whether or not or how scripts should be verified prior
to execution.

Has anybody considered implementing this concept for /bin/sh, possibly
tied into /etc/profile or securelevel?  Or is this (as dynamically)
possible via veriexec?

-Jan
Permalink | Reply | 8 comments |
headers
Thor Lancelot Simon | 23 Sep 2010 13:35
Picon
Favicon

Re: execution policy for shells

On Wed, Sep 22, 2010 at 10:22:39PM -0400, Jan Schaumann wrote:
> Hello,
> 
> I just stumbled upon this:
> http://technet.microsoft.com/en-us/library/dd347628.aspx
> 
> Apparently, Microsoft's Powershell has the concept of an Execution
> Policy specifying whether or not or how scripts should be verified prior
> to execution.
> 
> Has anybody considered implementing this concept for /bin/sh, possibly
> tied into /etc/profile or securelevel?  Or is this (as dynamically)
> possible via veriexec?

It's "possible via veriexec" inasmuch as you can allow only the one
true blessed shell to run, and implement whatever policy you care to
in that shell.  This is how the VMS dynamic linker protected the rest
of the system from bad shared objects...
Permalink | Reply | 7 comments |
headers
Brett Lymn | 23 Sep 2010 13:52
Picon

Re: execution policy for shells

On Thu, Sep 23, 2010 at 07:35:14AM -0400, Thor Lancelot Simon wrote:
> 
> It's "possible via veriexec" inasmuch as you can allow only the one
> true blessed shell to run, and implement whatever policy you care to
> in that shell.  This is how the VMS dynamic linker protected the rest
> of the system from bad shared objects...

actually, veriexec can be more subtle than that.  You can bless
certain shell scripts but deny the direct invocation of the shell
interpreter.  That means that #!/bin/powershell at the top of the
script will invoke the powershell interpreter _but_ trying to run
/bin/powershell from the command line will fail.  Of course, extreme
care needs to be taken when writing the scripts to ensure the user
cannot inject shell commands into the interpreter.

(yes, I do know powershell is a MS thing you can tell because it has
the weird inconsistencies despite being recently written)

--

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thor Lancelot Simon | 23 Sep 2010 13:54
Picon
Favicon

Re: execution policy for shells

On Thu, Sep 23, 2010 at 09:22:21PM +0930, Brett Lymn wrote:
> On Thu, Sep 23, 2010 at 07:35:14AM -0400, Thor Lancelot Simon wrote:
> > 
> > It's "possible via veriexec" inasmuch as you can allow only the one
> > true blessed shell to run, and implement whatever policy you care to
> > in that shell.  This is how the VMS dynamic linker protected the rest
> > of the system from bad shared objects...
> 
> actually, veriexec can be more subtle than that.  You can bless
> certain shell scripts but deny the direct invocation of the shell
> interpreter.  That means that #!/bin/powershell at the top of the

In which case you can't even have an emergency login shell on your
system.  Not 100% sure what I think about that one.

Thor
Permalink | Reply | 1 comment |
headers
Brett Lymn | 23 Sep 2010 14:46
Picon

Re: execution policy for shells

On Thu, Sep 23, 2010 at 07:54:56AM -0400, Thor Lancelot Simon wrote:
> > 
> > actually, veriexec can be more subtle than that.  You can bless
> > certain shell scripts but deny the direct invocation of the shell
> > interpreter.  That means that #!/bin/powershell at the top of the
> 
> In which case you can't even have an emergency login shell on your
> system.  Not 100% sure what I think about that one.
> 

Only if you set the policy up that way, you can have an interactive
shell but not "bless" any shell scripts for that shell just like you
would any other executable object but what veriexec will let you do
is, say, install perl and be able to run a bunch of perl scripts
(because they are "blessed") but not invoke perl from the command line
but only if that is what you choose to do, you could just as easily
let perl be run from the command line if you want to.  I thought
having the distinction between directly running the interpreter and
running scripts using that interpreter was sort of a useful thing.

--

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Schaumann | 23 Sep 2010 18:17
Favicon
Gravatar

Re: execution policy for shells

Brett Lymn <blymn <at> baea.com.au> wrote:
> On Thu, Sep 23, 2010 at 07:35:14AM -0400, Thor Lancelot Simon wrote:
> > 
> > It's "possible via veriexec" inasmuch as you can allow only the one
> > true blessed shell to run, and implement whatever policy you care to
> > in that shell.  This is how the VMS dynamic linker protected the rest
> > of the system from bad shared objects...
> 
> actually, veriexec can be more subtle than that.  You can bless
> certain shell scripts but deny the direct invocation of the shell
> interpreter.

But that requires me explicitly stating which scripts are allowed to
run, right?  What I'm looking for is a way to allow any arbitrary script
to be executed so long as it's signed by an entity I previously
identified.  If no signature is found, the signature does not verify or
is not by the entity I declared, then execution is refused.

-Jan
Permalink | Reply | 3 comments |
headers
Thor Lancelot Simon | 23 Sep 2010 20:56
Picon
Favicon

Re: execution policy for shells

On Thu, Sep 23, 2010 at 12:17:20PM -0400, Jan Schaumann wrote:
> > 
> > actually, veriexec can be more subtle than that.  You can bless
> > certain shell scripts but deny the direct invocation of the shell
> > interpreter.
> 
> But that requires me explicitly stating which scripts are allowed to
> run, right?  What I'm looking for is a way to allow any arbitrary script
> to be executed so long as it's signed by an entity I previously
> identified.  If no signature is found, the signature does not verify or
> is not by the entity I declared, then execution is refused.

So you need the shell to be the thing whose fingerprint is known to the
kernel, and the interpreted scripts to be known to the shell.

Thor
Permalink | Reply | 2 comments |
headers
Jan Schaumann | 23 Sep 2010 21:06
Favicon
Gravatar

Re: execution policy for shells

Thor Lancelot Simon <tls <at> panix.com> wrote:

> So you need the shell to be the thing whose fingerprint is known to the
> kernel

Yes.

>, and the interpreted scripts to be known to the shell.

I'd like to avoid having to know in advance the scripts the shell might
run.  I'd rather say "only run a scrip -- any script -- if it's signed
by X".

-Jan
Permalink | Reply | 1 comment |
headers
Thor Lancelot Simon | 24 Sep 2010 18:59
Picon
Favicon

Re: execution policy for shells

On Thu, Sep 23, 2010 at 03:06:39PM -0400, Jan Schaumann wrote:
> Thor Lancelot Simon <tls <at> panix.com> wrote:
>  
> > So you need the shell to be the thing whose fingerprint is known to the
> > kernel
> 
> Yes.
> 
> >, and the interpreted scripts to be known to the shell.
> 
> I'd like to avoid having to know in advance the scripts the shell might
> run.  I'd rather say "only run a scrip -- any script -- if it's signed
> by X".

I think you're not really getting my operative definition of "known to".

It's a lot easier to validate a RSA signature in the shell than in the
kernel (though if you want to implement software public key operations
in /dev/crypto be my guest).

--

-- 
Thor Lancelot Simon	                               tls <at> rek.tjls.com
  "All of my opinions are consistent, but I cannot present them all
   at once."	-Jean-Jacques Rousseau, On The Social Contract
Permalink | Reply | 0 comments |
headers
NetBSD Security Officer | 29 Sep 2010 02:04
Picon

NetBSD Security Advisory 2010-007: Integer overflow in libbz2 decompression code


		 NetBSD Security Advisory 2010-007
		 =================================

Topic:		Integer overflow in libbz2 decompression code

Version:	NetBSD-current:	source prior to September 21, 2010
		NetBSD 5.0:		affected
		NetBSD 4.0.1:		affected
		pkgsrc:			bzip2 package prior to 1.0.6

Severity:	potential remote DoS or code-injection attack

Fixed:		NetBSD-current:		Sep 20, 2010
		NetBSD-5 branch		Sep 23, 2010
		NetBSD-5-0 branch	Sep 23, 2010
		NetBSD-4 branch		Sep 23, 2010
		NetBSD-4-0 branch	Sep 23, 2010
		pkgsrc 2010Q2:		bzip2-1.0.6 corrects this issue

Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract
========

The bzip2/bunzip2 functions and the libbz2 library provide compression
and decompression functionality similar to gzip/gunzip and libgzip but
with better compression ratio and worse compression performance.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane