Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Hardening checklist, take 2
View unanswered posts
View posts from last 24 hours

Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message

Joined: 16 Apr 2002
Posts: 18289

PostPosted: Fri Nov 12, 2010 8:13 pm    Post subject: Hardening checklist, take 2 Reply with quote

Had lots of problems the first time around, so started over with a VM and hardened toolchain. gradm is installed, but not enabled (which is what I'm planning to do next unless I've missed something).

I've emerged a few things since switching to the kernel with grsec & pax enabled, so I think that works at least at a basic level. Is there anything below I need to correct first? Anything else before moving on to gradm? Thx.

Should I fix something for ET_EXEC and memcpy?
Mode: blackhat
Linux localhost 2.6.34-hardened-r6 #12 PREEMPT Sat Nov 6 20:30:58 MDT 2010 x86_64 QEMU Virtual CPU version 0.12.5 AuthenticAMD GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 29 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (PIE)            : 35 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (PIE)      : 27 bits (guessed)
Shared library randomisation test        : 29 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 35 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 35 bits (guessed)
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, PIE)         : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE)         : Vulnerable

I selected the grsec server option and that's it. Should I be concerned about all of the disabled options? I didn't see any GCC related kernel options.
# ./  --kernel
* Kernel protection information:

  Description - List the status of kernel protection mechanisms. Rather than
  inspect kernel mechanisms that may aid in the prevention of exploitation of
  userspace processes, this option lists the status of kernel configuration
  options that harden the kernel itself against attack.

  Kernel config: /proc/config.gz

  GCC stack protector support:            Disabled
  Strict user copy checks:                Disabled
  Enforce read-only kernel data:          Disabled
  Restrict /dev/mem access:               Disabled
  Restrict /dev/kmem access:              Disabled

* grsecurity / PaX: Custom GRKERNSEC

  Non-executable kernel pages:            Enabled
  Prevent userspace pointer deref:        Disabled
  Prevent kobject refcount overflow:      Enabled
  Bounds check heap object copies:        Enabled
  Disable writing to kmem/mem/port:       Enabled
  Disable privileged I/O:                 Enabled
  Harden module auto-loading:             Enabled
  Hide kernel symbols:                    Enabled

* Kernel Heap Hardening: No KERNHEAP

  The KERNHEAP hardening patchset is available here:

And just in case:
# emerge --info
Portage (hardened/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r2, 2.6.34-hardened-r6 x86_64)
System uname: Linux-2.6.34-hardened-r6-x86_64-QEMU_Virtual_CPU_version_0.12.5-with-gentoo-1.12.13
Timestamp of tree: Fri, 12 Nov 2010 17:15:02 +0000
app-shells/bash:     4.1_p7
dev-lang/python:     2.6.5-r3, 3.1.2-r4
sys-apps/baselayout: 1.12.13
sys-apps/sandbox:    2.3-r1
sys-devel/autoconf:  2.65-r1
sys-devel/automake:  1.11.1
sys-devel/binutils:  2.20.1-r1
sys-devel/gcc:       4.3.4, 4.4.4-r2
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.10
sys-devel/make:      3.81-r2
virtual/os-headers:  2.6.30-r1
CFLAGS="-march=athlon64 -O2 -pipe"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=athlon64 -O2 -pipe"
FEATURES="assume-digests buildpkg collision-protect distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="acl amd64 berkdb bzip2 cli cracklib crypt cxx gdbm hardened iconv justify kvm mmx modules mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pic python readline sse sse2 ssl sysfs tcpd urandom zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-2" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nouveau nv r128 radeon savage sis tdfx trident vesa via vmware voodoo" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

First attempt for the morbidly curious
Don't even pause and ask them why. Turn around and say goodbye.
Back to top
View user's profile Send private message

Joined: 05 Aug 2004
Posts: 3789
Location: sleeping in the bathtub

PostPosted: Sat Nov 13, 2010 3:49 pm    Post subject: Reply with quote

You're paxtest results are more or less identical to mine, and everyone else's I've seen.

From what I know, ET_EXEC is only relevant to non-pie binaries, which should be a very small minority on a gentoo system with a hardened toolchain, you can use scanelf to see if a particular executable is affected (eg `scanelf -a /usr/bin/*`), should be either ET_DYN or ET_EXEC.

Not too sure on why the memcpy tests always return "vulnerable", but it's the normal result from what I've seen.

I've never seen a recommendation for enabling "GCC stack protector support" from the hardened or grsec people, and it has been known to cause some issues (maybe incompatible with pax?), so I've never played with it, and it's still marked experimental anyways.

"Strict user copy checks" is a compile-time only thing, so enabling it shouldn't have any affect on a running kernel, it'll just cause a compile failure if a problem is found.

Dunno about "Enforce read-only kernel data", can't find any reference to it...

Should be safe (and a good idea) to restrict/disable both mem and kmem under /dev, ie "CONFIG_DEVKMEM" should be disabled and "CONFIG_STRICT_DEVMEM" enabled.
May cause issues with some software depending on what you need but I've had no issues.
On the other hand, if you need either enabled "CONFIG_GRKERNSEC_KMEM" offers more or less the same protection anyways.

"Prevent userspace pointer deref", ie uderef, for a 64-bit kernel you should probably read this.
For what it's worth, I have it enabled on a 64-bit host with no noticeable issues, I don't think virtualbox works with it (and probably some other virtual machines), but anything using kvm whould work just fine under a fully hardened host.

Never came across KERNHEAP before, I'd love to know what it offers that pax doesn't, pity the only patches that seem to be available are for 2.6.33...

"You have to invite me in"
Back to top
View user's profile Send private message

Joined: 16 Apr 2002
Posts: 18289

PostPosted: Wed Nov 17, 2010 6:18 am    Post subject: Reply with quote

Thanks. I guess that mostly means everything is more or less OK. I'm rebuilding the kernel now with the CONFIG_DEVKMEM / CONFIG_STRICT_DEVMEM changes (CONFIG_GRKERNSEC_KMEM was already enabled).

uderef was a little over my head, but I got enough out of it, thanks. I think I'll leave it off for now and do some more research.
Don't even pause and ask them why. Turn around and say goodbye.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum