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

[Javier Juan Martínez Cabezón]

> I suggest you do some more reading at grsecurity.net or even the
> OpenBSD mailing list. I haven't got time to hunt down the two references
> that stick in my mind but keep your ears open and you may realise one
> of the kernel exploits could/can/will do just that. Do you really
> believe it's impossible??!!
>
I give you proofs because  the arguments you defend are wrong, give
proofs about the oposite if you can.

I told you, with a secure TPE (so scripts fully controlled) tell me
how to write one kernel exploit under bash without calling external
code.


>>> Shall we get rid of file permissions because we have RBAC. We could
>>> but I can't see that happening and for good reason.
>
>> file permissions are discrectional, rbac mostly mandatory
>
> I have no idea what you are arguing with, you just keep trying to twist
> what I say because you have a bee in your bonnet about MACs as the
> answer to everything and a panacea, they aren't but they are useful as I
> have said. Personally I wouldn't swap an OpenBSD kernel for the Linux
> one with RBAC on my servers atleast. One day with a risky setup, I
> might in that instance. I wonder why kernel.org didn't use RBACs,
> especially RSBAC or even chroot. How embarrassing for such an automated
> attack to get through. Is bugzilla.kernel.org still down? That wouldn't
> have happened if they were using OpenBSD. It might be a good idea to use
> a different kernel to the one they are hosting anyway even with many
> eyes. And before you think well this is just me clutching at straws with
> your tunnel vision, it relates exactly to what I was talking about
> of likelihood of use.

I have never said to eliminate DAC. I just told that ONLY DAC as
openbsd do is a bad option and insecure.
You can substitute DAC with RBAC (and RSBAC gives an option to do it).

Now DAC and RBAC are layered, RBAC can be secure without DAC, DAC
WOULD NEVER be secure without RBAC.


> What is root, it is the root of the system not just a user. If it
> didn't exist the kernel wouldn't be able to turn RBAC off now would it.
> You have been drawn in by the wonderful marketing of imagine a system
> where root doesn't exist. Would your analogy be the kernel recreates
> root. If so, fine it makes no difference but is less correct.

I repeat you (and get your ears cleaned) UID 0 is only relevant UNDER
DAC approach.

RBAC doesn't use UIDS just roles read about rbac AGAIN. And UID 0
under rbac can do NOTHING. UID 0 can't switch off nothing only role
admin can do it, and usually is not UID 0, in rsbac is UID 400.

Some binaries with independency of which user executes it, change to
their own role and can do ONLY which his role can do., for example my
syslog-ng role when executed can only access in append mode to logs
files and mapping libraries under /lib, can just access to /dev/log. A
exploit ran against syslog will NOT GET full control over the system
even when ran under root account without dropping just to what his
role can do.

Root in a DAC can do which it does because the capabilities, in my
system (I told you again) root has not capabilities, is just a simple
user.

As you can suppose this user 400 doesn't launch daemons (neither init)
and run any software he just administrate the policy, and nobody can
suid to his uid without getting authenticated (password) against UM
module, so there is not way to get suid to his account in a exploit
approach.

I told you many times that TPE under proper RBAC is secure, because
only a bash script without calling extern code could be launched as an
exploit, so it's nearly impossible to do it. Write me a bash script
kernel exploit if you can.

Even with that this role admin or authority could be fixed forever
just revoking to his role these privileges.


> And yet your kernel has bugs added every day without much security
> consideration. What you don't understand is that RBAC is a security
> layer that the root of the system has control of. What can
> your /sbin/init do, what can the kernel do? Some rootkits can actually
> go the other side of the kernel even, far above where RBACs are.

Read the orange book, this is the question because mandatory access
controls exists to confinate damage and avoid them. My init can't suid
to secoff UID, and he can't only call scripts and nothing more. Getty
runs with his own role, scripts with their own, login with it's own
and init with it's own. ROOT DOES NOT CONTROL RBAC, RBAC controls him.

There is no way that a rootkit could access to kernel memory,
/dev/mem, ioports an alike devices are fully controlled and module
interfaz too and kernel sources too. Tell me how the hell can anyone
launch a ring 0 rootkit, and give proofs as I did a not simple search
in grsec or openbsd sites.


> I repeat it ALL depends on the application, even the hardware. You
> could reduce the Linux kernel right down to protect the RBAC. Which
> was my original point.
>
RBAC IS the kernel, is the PCB. The PCB protects himself from
userland, and root is part of this userland, and for this reason root
has not rights over it, it has them over him. By this reason the
access control is mandatory.