Proactive Security Roadmap

Status

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

• Priority: LowPriorityBR

• People: MartinPittLead, AndrewMitchellSecond, MartinPittQueue, AndrewMitchellQueue[BR]]

• Contributors: MattZimmermanBR

• Interested: MartinPitt, MatthiasKlose, BrandonHale, AndrewMitchellBR

• Status: DraftSpecification, BreezyGoal, UduBof, DistroSpecificationBR

• Branch: BR

• Malone Bug: BR

• Packages: BR

• Depends: BR

• UduSessions: done (colin: err, how many did you have? format is: sessions_had(remainder))BR

Introduction

Establish a strategy for implementing proactive security features in Ubuntu.

Rationale

(colin: a rationale would be nice, as to why you want to be proactive about things)

Scope and Use Cases

• Privilege reduction
  • Run cron as non-root?
  • Run dhclient3 as non-root?
  • Run dhcpd3 as non-root?

  • Change unix_chkpwd from suid root to sgid shadow (see [http://bugs.debian.org/155583 #155583])

• Compile-time stack protection?
• Non-executable stack for i386?

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

• MAC (SELinux) -> Separate BoF

• Find ways to prevent exploitations of common vulnerabilities.

Implementation Plan

(colin: any idea how you want to implement it?)

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; packaging is available.

• Port some /proc restrictions which can be enabled/disabled at runtime.

• Port randomisation patches: PID, TCP sequence numbers, TCP source ports
• Delay the respawning of repeatedly crashing applications to prevent brute force 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.

Outstanding Issues

(colin: is there anything that'd crop up as an issue?)

UDU BOF Agenda

• Jamie will research whether there are things exploitable in exec-shield which aren't in PaX.
• Evaluate chroot hardening patches.

UDU Pre-Work

• Research privilege requirements of cron

  MartinPitt: 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 a bit; I do not have an idea how to deroot this either, it's the same problem.)

• Research privilege requirements of dhclient3

  MartinPitt: normal user with CAP_NET_RAW and CAP_NET_BIND_SERVICE; needs a suid wrapper to call /etc/dhcp3/dhclient-script; prototypical package available; pending security review of dhclient-script (proper quoting, etc.)

• Research privilege requirements of dhcpd3

  MartinPitt: normal user with CAP_NET_RAW and CAP_NET_BIND_SERVICE for initialization phase; can be dropped after socket creation; prototypical package available

• Search for implicit dependencies on inetd via netbase

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

• Determine requirements for compile-time stack protection in gcc (4.x?)

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