[ubuntu-hardened] Re: Some thoughts about the hardened schema

Wed Apr 13 08:40:31 CDT 2005

El mié, 13-04-2005 a las 03:32 +1000, Jamie Jones escribió:
> G'day,
> 
> I've been going over the ubuntu hardened schema here
> http://pearls.tuxedo-es.org/misc/ubuntu-hardened-schema.png and I had a
> few questions and thoughts I'd like to share. (I did check the the list
> so don't flame me too much if I missed something)

No worries  ;)

> 1) libsafe is missing from the schema. Does that mean it wasn't
> considered or it was rejected for some reason ? I've been using that to
> provide ssp like protection for binary only programs (many commercial
> games come to mind). I haven't had any major issues with it (well maybe
> the amd64 package, should come a 32 bit version to stop OOo from not
> starting because there was no 32bit libsafe to load, but to me the bug
> is OOo isn't 64bit clean)

Not rejected, it was considered though, but, as our first user-land
solution for countering stack smashing, we choose it rather than
libsafe.

You missed the stack frame re-arrangement that SSP introduces, and you
missed the *active* development status of it, among an extensive amount
of documentation and probed performance.

LD_PRELOAD is weak, shared library redirection of functions is also weak
(at least is much less clean than simply getting in touch with the
toolchain and modifying the parts at issue, and doing it well).

Anyways, libsafe is available in the repositories and users can feel
free to use it if they think that's the way to go or it just makes any
more advantage.Protecting binary-only programs can be done at
kernel-level.

We are dealing with something that will advert us when something is
wrong, minimizing the effects and thus providing more flexibility for
*fixing* the application at issue, not living with something weak 'cos
we have a "protection layer" in it's top.

There's no fascist "use X and not any other thing" but "X is the
default, but you can use Y if you want".

The default solution is supported thus, you don't need to waste the time
contacting the upstream about something that we have broken.
The optional solution is not "officially" supported, it means, we
*can't* assess the risk of someone who uses Y solution which makes
his/her Z application to break, but he/she can get support back from the
community itself.

> 2) I noticed that RSBAC and SE Linux are listed, with SE Linux the
> default solution. Does SE Linux have an advantages over RSBAC ? It seems
> to me that RSBAC is more flexible, with module support for PAX flags,
> and other useful features like the Dazuko module. SE Linux might have
> similar features but if it has I've missed them. If that's the case
> could someone point me in the right direction to check it out.

If someone who wants to maintain and lead the development of a RSBAC
herd shows up, then RSBAC will be available, at least up-to-date
packages and such.

I've said it many times, but I will say again:

 - RSBAC patches the kernel source, *IT'S NOT* available in the mainline
   nor has any warranty of compatibility, ABI compliance, etc; from the
   upstream  (mainline *must* assess such
   risk, the RSBAC fellows not).
-  SELinux is used widely and has a *consistent* user base: Red Hat.
   Collaboration for policy fine-tuning and other things (ie. kernel
   work) is required, among that mainline availability ensures that
   things are *sufficiently* tested and known to work.
-  "PAX flags support", "Dazuko".... good. Looks like you miss a couple
   of other things of SELinux (it can handle memory permissions among
   a *big* couple of other ones). Anyways, I've talked about them
   before, and there's an *huge* amount documentation over there.

   About Dazuko, http://www.dazuko.org/files/dazuko-2.0.6.tar.gz.
   Review that tarball, look inside, and look in the *lsm*.{c,h} files.

Amen (again).

> 3) I noticed that PAX and Exec Shield are listed as supported. While I
> prefer PAX to Exec Shield, both do ASLR right ? That would mean that
> they both drain entropy from the kernel each time they do ASLR right ?
> Would Robert Loves netdev-random patch (2.6.10 version found in
> http://dev.gentoo.org/~tseng/kernel/hardened-patches-2.6-10.3.tar.bz2 )
> be suitable for adding more entropy back into the system (or cutting off
> that source if you are suitably paranoid)

You prefer PAX rather than ES. I did in the past. Now some parts of ES
are getting mainline. I refer to my last words about mainline and
they're responsibility.
They both do ASLR, yes.

On the netdev-random patch, sincerely I doubt in the advantage, it might
be good for machines with high network activity, but still not necessary
and also Ubuntu is directed to desktops, but lately there's an effort
for making it "server capable".
It introduces *too many* changes, thus it needs a careful review to see
if it's worthy to assess with the risk of breaking something (or
overloading maintenance, more overload, less work done).

> Thanks for taking the time to read this.

My pleasure, it's always good to hear back ;)

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo at gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20050413/b6b4af60/attachment.pgp