Proactive Security Roadmap

Status

• Created: Date(2005-04-24T00:17:26Z) by MattZimmermanBR

• Priority: LowPriorityBR

• People: MartinPittLead, AndrewMitchellSecond BR

• Contributors: MattZimmermanBR

• Interested: MartinPitt, MatthiasKlose, BrandonHale, AndrewMitchellBR

• Status: DraftSpecification, BreezyGoal, DistroSpecification, ColinWatsonQueue, SimonSharwoodQueueBR

• Branch: BR

• Malone Bug: BR

• Packages: BR

• Depends: BR

• UduSessions: 2(0)BR

Introduction

Establish a strategy for implementing proactive security features in Ubuntu.

Rationale

We want to reduce the risk of security holes in Ubuntu systems by reducing the number of potential attack vectors and find general solutions for preventing common classes of vulnerabilities. This confines the impact of actual vulnerabilities to a minimum.

Scope and Use Cases

• We will patch the Ubuntu kernel to provide protection against common attacks and reduce the privileges of system daemons so that they run with least privileges.
• Users may find that some programs need fixes as a result of these protections, and so we will provide a method to disable the kernel improvements at runtime.
• If a community member supplies packages, we will have modified gcc and kernel packages with hardened patches available in universe.

Implementation Plan

Data Preservation and Migration

Does not apply here.

Packages Affected

Kernel:

• Port the OpenWall patch that prevents exploitation of unsafe temporary file creation; it is really trivial; add a proc file to be able to enable/disable at runtime.

• Provide a grsecurity kernel in universe, if a community member is interested to care about it; [http://people.ubuntu.com/~pitti/arch/martin.pitt@canonical.com--2005/linux-hardened--devel--2.6.10/ packaging] is available.

• Extract and port some of grsecurity's /proc restrictions which can be enabled/disabled at runtime:

  • Users can only see their own processes; this will keep them from e.g. seeing confidential command line arguments of other processes, which is still a very common mistake.
  • Hide memory addresses from map files: make it harder to deploy successful exploitations of heap overflows.
• Extract and port randomization patches from grsecurity:
  • PID: Prevent the prediction of PIDs for child processes to make it harder to exploit race conditions, and avoid information leaks.
  • TCP sequence numbers: Make it harder to hijack TCP connections.
  • TCP source ports: Drastically increase the average time for TCP reset attacks.

prelink:

• Prelinked applications leave a huge /var/log/prelink.log which contains memory address; patch prelink to not dump addresses.

gcc:

• If a community member is interested, we can provide SSP/Fortify/etc. gcc packages in universe, but we will not put them into main and use them as a default as long as upstream does not adopt a solution.

dhcp3-client:

• Currently dhclient runs as root, which is much more than necessary.

• Privilege requirements: normal users with CAP_NET_RAW and CAP_NET_BIND_SERVICE; needs a suid wrapper to call /etc/dhcp3/dhclient-script

• dhclient-script must be security reviewed (proper quoting, etc.).

• MartinPitt has a prototypical package, will upload it into Breezy soon.

dhcp3-server:

• Currently dhcpd runs as root, which is much more than necessary.

• Privilege requirements: normal user with CAP_NET_RAW and CAP_NET_BIND_SERVICE for initialization phase; these can be dropped after socket creation.

• MartinPitt has a prototypical package, will upload it into Breezy soon.

inetd:

• This package is currently installed by default as part of the base system; since it is a daemon running as root, but is not used much any more, it is desirable to throw it out to Supported.

• MartinPitt compiled a list of all packages in main which use inetd on the InetdUsage page.

unix_chkpwd:

• Change /sbin/unix_chkpwd from setuid root to setgid shadow by default.

• Since this breaks NIS lookups (see [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155583 #155583]), the permissions need to be changed back to setuid root if the package nis is installed. There is no clean way to achieve that, though. After consulting Scott, the least evil hack seems to be:

  • nis postinst: If unix_chkpwd does not yet already have an override, do dpkg-statoverride to set the permissions to root:root 4755.

  • nis prerm: If the current permissions of unix_chkpwd is root:root 4755 and there is a stat override for it, remove the override to restore permissions.

Outstanding Issues

Desirable for the future:

• Exponentially delay the respawning of repeatedly crashing applications to prevent brute force attacks (eventually finding the correct offset of memory locations for buffer overflow attacks).
• Evaluate chroot hardening patches.
• Memory protection: Jamie will research whether there are things exploitable in exec-shield which aren't in PaX.
• Compile-time stack protection.
  • mudflap comes with gcc 4.0, but does not help in any way to improve proactive security

  • [http://www.research.ibm.com/trl/projects/security/ssp/ SSP] currently offers the [http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf most effective protection], but does not (currently) work with 4.0 and is unlikely to be accepted upstream.

  • There is another project called FORTIFY_SOURCE which has a better chance to be eventually accepted upstream.
  • We will not support any solution that is not at least considered upstream.
• Runtime memory protection
  • Since there is no accepted upstream solution, we will not support that in main for now. However, if a community member wants to provide universe kernels, we would greatly appreciate that.

  • Some info is already compiled at http://ubuntu.com/wiki/UbuntuHardened.

• Reduce the privileges of cron.
  • Parsing the crontabs as normal user and introducing a minimal setuid wrapper for actually executing the commands as the target user will not help to improve security; the remaining stuff (timer and signal handling) does not accept user input and thus is not very error prone. I do not really have a good idea about this. (Note: atd also runs with root privileges, it just hides them pretty well; I do not have an idea how to deroot this either, it's the same problem.)
• Support SELinux out of the box; there is a [wiki:SELinux separate BoF] about this topic.