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

[Jamie Jones]

On Wed, 2005-04-13 at 15:40 +0200, Lorenzo Hernández García-Hierro
wrote:
> El mié, 13-04-2005 a las 03:32 +1000, Jamie Jones escribió:
> > G'day,
[snip]
> 
> > 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.

I didn't miss SSP or the active development. SSP is a vastly better
solution for protecting anything you have the source to. I used to
rebuild the important packages on my old Debian server with SSP enabled.

> 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).

Agreed.

> 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.

I was considering libsafe from the point of view of "how can I protect
my system from some application that can't be fixed". If I ever
needed/wanted to run something like that (eg distributed.net) I would
like any practical extra layers of protection I can get. I do realise
the libsafe upstream is effectively dead. There are other kernel-level
methods that protect against ret2libc ?? (I'm very aware that libsafe is
partial protection at best)

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

I didn't mean to imply otherwise, I just though it was an oversight as I
am new to Ubuntu.

> 
> 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.

Fair enough. I've just been plowing through the documentation, I'm
looking for the practical solution, which seems to be SELinux is in
kernel now, so use it.

> 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).

True. But even SELinux started as a patch once :)

> -  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.

Better tested is another nice practical reason to me. Although wasn't
there some American company claiming to have patents on it a while ago ?

> -  "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.

Still wading through the documentation, seems like I missed something,
but I'll get to it eventually.

>    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).

I have a strong feeling that you had answer questions like this
repeatedly. I do know that it has lsm support, I am under the impression
that there are problems with stacking multiple lsm modules in the
kernel, which let to my understanding that it would work "better" with
RSBAC. I can see practical uses for this on a samba server.

> > 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.

I've never seen an unbiased comparision between PAX and ES actually.
Other then paxtest is there any other testing tool I could use to make
an evaluation on how they perform against each other ? (I'm not keen on
running a "real" exploit to test ATM)

> 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".

Ubuntu's not server capable ?? I've already deployed it as a public web
server. Works fine for me.

> 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).

I've looked at the patch several times. At one stage I ported one of the
early 2.6.x patches to 2.6.8 for one of my systems. It was a simple
patch actually (simple enough that even I could do it). It adds a define
SA_NET_RANDOM in signal.h that is set to equal SA_SAMPLE_RANDOM if
CONFIG_NET_RANDOM is set, otherwise SA_NET_RANDOM equals 0.
It then adds that SA_NET_RANDOM define to the request_irq statement in
the network driver. 

Personally I turn this on, because the machine that it runs on needs a
fair bit of randomness and doesn't have many sources.

Out of curiosity, if I'm subscribed to the list, and I'm CC'ed am I only
supposed to get one copy of the email ??

Thanks

Jamie

-- 
GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments
PGP Key ID 0x42E2C1E5
Fingerprint 3C77 9621 84C5 C32F D409 A38D A035 7E65 42E2 C1E5
-------------- 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/20050414/5289410c/attachment.pgp