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

["Javier Juan Martínez Cabezón" <tazok.id0@gmail.com>]

2011/12/12 Kevin Chadwick <ma1l1ists@yahoo.co.uk>
>
> On Mon, 12 Dec 2011 16:23:21 +0100
> Javier Juan Martínez Cabezón wrote:
>
>
>
> Actually I was talking about TPE in Linux not being potentially as
> effective as noexec.
>
>
> You still can't execve and I believe noexec on Linux now prevents that?
>


I repeat, you don't need execve to launch untrusted code. When you do
"perl /tmp/somenastyscript", the script works even if you mounted as
noexec /tmp. This happens because the execve is only launch in
/bin/perl that "usually" has exec granted, in mynastyscript you only
just need read privileges granted in noexec.

None TPE without mandatory access control is effective, noexec is as
useless as TPE against script interpretation. The main difference is
that in linux you can implement a fully secure TPE, not under openbsd
since it lacks of rbac approachs.

Only a rbac can assure TPE restricting script interpretation as this:

perl execve ----->run under role perl.----->check-------- if script
marked trusted ----> change to user role and do what you have to do
                                                  --------> if script
untrusted (didn't mark as trusted)---> don't permit read and as result
don't make transition..

Since role perl has only read privileges against trusted scripts and
nothing else, TPE is secure because every untrusted code is prevented
from execution.

Under rsbac, execution is controlled under EXECUTE privilege with
execve and related calls and with MAP_EXEC for library mappings., TPE
is just a less approach under it because nothing has EXECUTE
privileges if they are not /bin /sbin or /lib directories is a result
of the less priviledge approach of rbac.

> Environment and monitoring at the time of updates and no dangerous
> actions like web browsing etc. etc. whilst the system is writable.

a bug in package software which privileges would grant to an attacker
with a crafted package exploiting a bug?, and if a privilege daemon is
running?

Your main problem is that you consider root trusted, and is not.

>
> An attacker is far less likely to get root on OpenBSD in the first
> place but I am not trying to compare the two systems here. I could
> reply with kernel attacks bypassing RBAC where execve would be
> helpful but I don't want merits of the two being turned into one
> of the many heated and pointless prevention versus protection debates.
> We choose our poisons and the right cocktail for each application. I
> also don't want to diverge so much from the ops original question which
> may preclude OpenBSD?.

who says that?, I'm sure that even with root account under my system
you don't get privileges at all, since root has not privileges. This
is the reason because a gnu/linux system could reach to B1 orange book
security level and openbsd to a simply C2, so linux can reach a
trusted status that openbsd no.

Openbsd only does a check, source code is full of if UID!=0 to everything.

It's a terrible error to think that openbsd has no errors, because
they have, it's wise to be prepared against bugs as MAC solutions
offers, it's of idiots to think that my software is perfect and free
of bugs and to think that they don't need MAC.


> We disagree and if you look hard enough this was the reason the /tmp
> bug was dismissed and has now been found to have been wrongfully
> dismissed, you can't deny it hardens a system to some degree. It's quite
> possible that you don't need to have perl or python installed. Though
> OpenBSD does use perl quite extensively but also like hardening suid,
> you could still restrict it's execution to groups. I'd also like to see
> you run an unauthorised and buggy Windows program through perl that
> could even listen to the network. (wine maybe authorised only for a set
> task due to user or business demands)
>
> Personally I see RBAC as a means of making it far more difficult to get
> root. Once someone has root there is no way I'd rely on RBAC to defend
> the memory, though we can always hope an attacker gives up on the extra
> layer in our defences, which was the main point. More is better (DID).
>
I repeat to you EXECUTE rights in a rbac system is granted just only
to /bin and /lib directories, none to /tmp. RBAC is sufficient to
avoid and confine this bug, you give me the reason because openbsd TPE
is useless, perl is present and uncontrolled as in "perl
/tmp/something". Try this it under openbsd with /tmp with noexec and
you will see that you can launch every script you want (without exec
calls but you dont need them to exploit vulnerabilities).

In rbac you can restrict PTRACE even to root, cap_sys_ptrace controls
it, PaX restricts the existence of PROT_EXEC PROT_WRITE simultaneously
in memory. Root under rbac neither can't mmap /dev/mem because he has
CAP_SYS_RAWIO removed, neither /dev/ports to I/O. Get realize that
root in rbac is not more than a simple user. Accessing to devices are
also fully controled and labeled according a B2 security level. If you
have modules interface they are controlled by CAP_SYS_MODULE that
could be revoked to root.

Suid to other uids are fully controlled, so nothing of suid(privuser)
to root. CAP_SYS_SUID check AND RBAC check, so both should be granted
to work.

Now please tell me how under this circunstances could root to make nothing.