> 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
