Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

Let's play your game as you keep mixing up contexts and you're the one
> making blanket statements not me and telling me you know what I know
> better than myself. I merely said that methods of breaking RBAC have
> been discussed and a kernel exploit is one of them.
>
> I haven't seen no methods in your mails of breaking nothing, only search
in the web ones.


> So show me how you can break out of the default apache on OpenBSD then?
>

With a bug in the portion of code with privileges. But it's not needed, any
bug in any software (as ports that are not audited) that gets root in
openbsd can kill apache process, but yeah it's clear that is nearly
impossible to get a remote hole in coreutils because they audit his
code.....



>
>
> RBAC is part of the kernel yes and so stored in memory. It is also a
> part of the kernel that is meant to be switchable. An exploit in the
> kernel can not only bypass RBAC or switch it off it can even situate a
> rootkit above the kernel leaving RBAC in place and having ALL rights
> aka the root of the system. Yes a perfect policy may prevent an exploit
> but it's equally possible that a perfect policy has to allow the
> exploit for desired functionality.
>
> What do you think that grsec and rsbac is SELinux alike?, Brad Spender
prove that selinux could be disabled because his stupid architecture of LSM
with exported symbols, grsec and rsbac doesn't work at the horrible way
that selinux does and has every code in main code everywhere, there is not
a magic button "switch_off" as SELINUX.  Grsec and Rsbac are not a part of
the kernel are the kernel itself. In rsbac every syscalls are intercepted,
any open(O_RDLY) calls done is intercepted and "substitute" by an READ_OPEN
request that should be granted to work, the portion of code that has open
calls has the rsbac calls ones there.

Can you patch the kernel on the fly without accessing devices? or without
modules interface? or without using ioports interface? just using syscall
interface? prove it, but don't get surprised if you get your funny process
killed because trying ring 0 changes from ring 3 is strictly forbidden
through it, supervisor mode is called I think...

If you can do it you can do then drivers from userspace without glue kernel
layer as fuse does (yes in your information is needed a kernel interface to
make it work, you can't do directly ring 0 interfaces with only userspace
code...


The question is what is more important, keeping attackers out or making
> sure your policies are good enough to stop them. I prefer OpenBSD for
> many reasons aside from just this anyway.
>
> At first sight it seems that you only want to make publicy of openbsd in a
gentoo hardened mailing list in a thread of a user that asks explicetly to
suggestions about it, at least with my answers he could check rbac data and
could save something from them. With yours answers I don't know what can he
take in clear.

You turned this into a bashing of OpenBSD and I'm not sure anyone here
> appreciates the hijacking of this thread, I should have known better
> than to mention OpenBSD here and almost removed it before sending, lets
> stop and agree to disagree. It's not the first time the importance of
> RBACs bug exploitation prevention versus bug removal and prevention at
> source has been discussed. Hopefully one day the Linux kernel will be
> as bug free and capable to be safely as static as OpenBSDs, I also hope
> OpenBSD gets a MAC one day too. Unfortunately I can't see either
> happening.
>

I only correct your mistakes and try to avoid that the user gets confused
by you,
I have been all the thread showing that you noexec implemention does not
work and exposed the reason about this and probable solutions. If you are
blind about this don't try to extend your blindness to the user that wants
suggestions.