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

[Grant]

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

Thank you for that.  What I'm looking for is one or more easy methods
for hardening my Gentoo systems.  I have two desktops, a laptop, and a
remote server.  The desktops and laptop run a hardened kernel with
grsecurity "Low" and the server runs a hardened profile and a hardened
kernel with grsecurity "Medium".   I don't run a hardened profile or
grsecurity "Medium" on the desktops or laptops because problems pop up
with Xorg apps and I don't have time to delve into them.  I need
something easy like enabling "Low", "Medium", or "High" and
recompiling the kernel.

What else would you recommend for me?

- Grant


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