Re: [gentoo-hardened] Profile switch: hardened to non-hardened?

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

Low grsecurity level:

linking restrictions
fifo restrictions
random pids
enforcing nproc on execve()
restricted dmesg
random ip ids
enforced chdir("/") on chroot

Medium grsecurity level (include low grsec level)

random tcp source ports
failed fork logging
time change logging
signal logging
deny mounts in chroot
deny double chrooting
deny sysctl writes in chroot
deny mknod in chroot
deny access to abstract AF_UNIX sockets out of chroot
deny pivot_root in chroot
denied writes of /dev/kmem, /dev/mem, and /dev/port
/proc restrictions with special gid set to 10 (generalmente wheel)
address space layout randomization
removal of addresses from /proc//[maps|stat]

high grsecurity level (include low and medium):

additional /proc restrictions
chmod restrictions in chroot
no signals, ptrace, or viewing processes outside of chroot
capability restrictions in chroot
deny fchdir out of chroot
priority restrictions in chroot
segmentation-based implementation of PaX
mprotect restrictions
kernel stack randomization
mount/unmount/remount logging
kernel symbol hiding

I took this from the grsecurity-hacktimes-v1.0.pdf. Let's see.

Low level: it enforces the chroot creation a bit and protect against
linking attacks. Protects against a few D.O.S. Is a very low low low
low level of security (this and nothing is something like the same.

Medium level: This introduces two things interesting, it protects
memory devices from alteration (rootkits could do this). It harden the
chroots creation closing some doors that could make people escape from
it. I think it has not sense that ASLR appears here since the stack
probably stays executable and so is not needed one return into libc
attack to get success. The same for the restrictions to
/proc/self/maps.

High level: It enforces the no executable stack and heap and the
mprotect restrictions to make it useful (so no memory could be
simultaneously writeable and executable. Now is needed the ASLR
approach and the hiding of address to make it useful against buffer
overflows.

It would be useful to activate Trusted Path Execution by default
(maybe could appears in custom level?).

2008/12/27 Grant <emailgrant@gmail.com>:
>> Why don't you tell what you didn't understand to us explain it
>> properly to you?. You can't assure nothing if you don't know what do
>> you need to assure.
>> You can't implement Mandatory Access Controls such as GRSEC rbac
>> without a bit of known. You need to make one policy for your system
>> and the kernel makes it enforcing their function.
>>
>> If you are not a sysadmin, how did you keep servers running?, to keep
>> servers you need to know how does them work internaly (for example DNS
>> rfc for DNS servers etc.).
>
> When I say I'm not a real sysadmin, I mean I have many duties and I'm
> not able to dive all the way in with sysadmin stuff.  This is due to
> time constraints.
>
>> As bad is not getting one MAC system running (as the RBAC of
>> grsecurity) as get one incorrectly configured running, for example
>> granting all capabilities (CAP_SYS_RAWIO...) to the user running
>> skype. GRSEC has one TPE function in himself read about it.
>>
>> Sorry but you have to read documentation (start for example with
>> gentoo hardened docs).
>
> You're right.  I thought that I was hardening my system just by
> running a hardened profile and a hardened kernel at the "Medium"
> Grsecurity setting.  Does that provide no extra security if I don't
> configure it beyond that?
>
> - Grant
>
>
>>>> Without hardened userland only in access controls. You can implement
>>>> for example one Trusted Path Execution with LIDS, RSBAC, GRSEC or
>>>> SELinux. They could try to stop crackers that gain unpriviledge access
>>>> to the host (with a remote exploit for example) to execute exploits to
>>>> scale priviledges. They could give you one least priviledge approach
>>>> (as PaX does) and other useful things, as isolation of daemons,
>>>> resources controls. And a lot of more. With TPE however, untrusted
>>>> scripts (exploits) could be launched without execution rights, and
>>>> even restricting the use of perl and python, you must grant your users
>>>> the access to bash.
>>>
>>> Thank you for taking the time to explain, but I'm afraid I don't
>>> understand.  I'm looking for things I can implement that don't require
>>> me to understand their inner workings.  This is not ideal, but I only
>>> have so much time to devote to sysadmin duties since I'm not a real
>>> sysadmin.  My server runs a hardened profile because it hasn't caused
>>> any problems, but running a hardened profile on my desktops has proven
>>> to be too difficult.  All of my systems run a hardened kernel but the
>>> only hardened feature I've enabled in the kernel is Grsecurity set to
>>> medium or low depending on the system.
>>>
>>> Do the hardened profile and hardened kernels do me any good without
>>> further configuration?
>>>
>>> - Grant
>>>
>>>>>> In terms of userland, non hardened profile doesn't protect you at all
>>>>>> against buffer overflows, you are removing one important security
>>>>>> layer. SSP protects you against buffer overflows in terms that the
>>>>>> vulnerable application gets killed when the canary is modified before
>>>>>> the execution of the arbitrary code. PIE protects you against return
>>>>>> into libc attacks that doesn't need an executable stack. PaX is not
>>>>>> perfect and needs them as complementary solutions. For example I think
>>>>>> that RANDEXEC was removed from PaX time ago, one buffer overflow that
>>>>>> uses return into libc attack could be succesfully against one
>>>>>> non-hardened binary. Since skype is a network oriented software...
>>>>>
>>>>> In what situations is a hardened kernel useful?
>>>>>
>>>>> - Grant
>
>