[gentoo-hardened] Just joined, normallly would lurk, but...

[gentoo-hardened] Just joined, normallly would lurk, but...

[lists]

 http://www.hut.fi/~jpkarna/papers/sign.html
I was wondering if anyone wanted to offer their opinion on schemes like these.
Until I dug up the link and posted to /. , it was the first I'd ever heard of idea of signing executables and syscalls.

Is there more info on this?


----------------------------------------
Free Mickey!
http://randomfoo.net/oscon/2002/lessig/

--
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Just joined, normallly would lurk, but...

[Alain Penders]

On Tue, Mar 11, 2003 at 04:06:58PM -0500, lists@m8y.org wrote:
>  http://www.hut.fi/~jpkarna/papers/sign.html
> I was wondering if anyone wanted to offer their opinion on schemes like these.
> Until I dug up the link and posted to /. , it was the first I'd ever heard of idea of signing executables and syscalls.
> 
> Is there more info on this?

There's a whole company based around this: http://www.tripwire.com/

tripwire is a standard part of most linux distributions these days, and we're
looking at adding tripwire-like functionality into portage.

As for the paper...  had the authors been familiar with tripwire, they might
have described some other security risks related to their implementation.  :)

Alain

--
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Just joined, normallly would lurk, but...

[lists]

Yes, I used tripwire before.  Although all it does is warn.  I like the idea of blocking.
Also, it merely tracks executables, it does not permit signed access to certain operations.
This method they gave has its problems.  No code signatures, only tracks single system call, apparently hardcoded passphrase (even if hashed), but unlike tripwire where it'd be up to *me* to notice the breakin based on the report, their system is more about preventing certain rights in the first place.

This is very interesting to me as I like giving people accounts on my machine, and something like rbash simply doesn't cut it.
For large systems, the ability to tightly restrict user rights would be very cool.

----------------------------------------
Free Mickey!
http://randomfoo.net/oscon/2002/lessig/
My key: http://m8y.org/keys.html

On Tue, 11 Mar 2003, Alain Penders wrote:
> There's a whole company based around this: http://www.tripwire.com/
> 
> tripwire is a standard part of most linux distributions these days, and we're
> looking at adding tripwire-like functionality into portage.
> 
> As for the paper...  had the authors been familiar with tripwire, they might
> have described some other security risks related to their implementation.  :)
> 
> Alain
> 
> --
> gentoo-hardened@gentoo.org mailing list
> 
> 

--
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Just joined, normallly would lurk, but...

[Alain Penders]

Yes, but:

- "bash -c 'source abc'" still works, and does not require abc to be 
  executable.  Hence, protecting against setting the x bit does not prevent 
  execution.

- All commands needed to compromise the system are already signed and +x'd.

Overall, this scheme doesn't seem to give any more security than a regular
tripwire does.  Giving access denied on a chmod() only educates a hacker on 
what does and does not work, and all he has to do is figure out how to 
compromise the system to the point where he can safely replace executables.

All you can do while he's doing that is read log files and hope you'll catch
the failed attempts he might have made.

Very similar to tripwire, where a cracker would have to jump through the same 
hoops to avoid detection.... and the detection process isn't any faster.

>From what I understand, SELinux and the new security framework in the 2.5 
kernels do a waaaaay better job at detecting all the various things one can 
screw with, and actually stopping crackers.

Alain


On Tue, Mar 11, 2003 at 04:37:40PM -0500, lists@m8y.org wrote:
> Yes, I used tripwire before.  Although all it does is warn.  I like the idea of blocking.
> Also, it merely tracks executables, it does not permit signed access to certain operations.
> This method they gave has its problems.  No code signatures, only tracks single system call, apparently hardcoded passphrase (even if hashed), but unlike tripwire where it'd be up to *me* to notice the breakin based on the report, their system is more about preventing certain rights in the first place.
> 
> This is very interesting to me as I like giving people accounts on my machine, and something like rbash simply doesn't cut it.
> For large systems, the ability to tightly restrict user rights would be very cool.
> 
> ----------------------------------------
> Free Mickey!
> http://randomfoo.net/oscon/2002/lessig/
> My key: http://m8y.org/keys.html
> 
> On Tue, 11 Mar 2003, Alain Penders wrote:
> > There's a whole company based around this: http://www.tripwire.com/
> > 
> > tripwire is a standard part of most linux distributions these days, and we're
> > looking at adding tripwire-like functionality into portage.
> > 
> > As for the paper...  had the authors been familiar with tripwire, they might
> > have described some other security risks related to their implementation.  :)
> > 
> > Alain
> > 
> > --
> > gentoo-hardened@gentoo.org mailing list
> > 
> > 
> 
> --
> gentoo-hardened@gentoo.org mailing list
> 

--
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Just joined, normallly would lurk, but...

[lists]

On Tue, 11 Mar 2003, Alain Penders wrote:

> Yes, but:
> 
> - "bash -c 'source abc'" still works, and does not require abc to be 
>   executable.  Hence, protecting against setting the x bit does not prevent 
>   execution.
> 
> - All commands needed to compromise the system are already signed and +x'd.

No disagreement on either point.  That's why I thought their idea of signing the executables themselves was cooler.  Their implementation was indeed rather trivial.
It is true the exploitable code is already signed, but normally an exploit is used to bootstrap one's self into the system.  Hard to do if the executable has tightly restricted rights to what operations it can perform, and you can't add executables to the system.

> Overall, this scheme doesn't seem to give any more security than a regular
> tripwire does.  Giving access denied on a chmod() only educates a hacker on 
> what does and does not work, and all he has to do is figure out how to 
> compromise the system to the point where he can safely replace executables.
> 
> All you can do while he's doing that is read log files and hope you'll catch
> the failed attempts he might have made.
> 
> Very similar to tripwire, where a cracker would have to jump through the same 
> hoops to avoid detection.... and the detection process isn't any faster.

Yep.  Tripwire makes one jump through a lot of hoops, but unless you're the sort of person who carries an MD5 sum of the tripwire executable on your person at all times, you can still be compromised...

> From what I understand, SELinux and the new security framework in the 2.5 
> kernels do a waaaaay better job at detecting all the various things one can 
> screw with, and actually stopping crackers.

*That* sounds much more promising.  If people are already building this into the kernel then I guess there's no point in my trying to do it myself :-)

I take it gentoo will simply use the 2.5 security framework?


--
gentoo-hardened@gentoo.org mailing list