mention Secure Computing's patent on Type Enforcement/SELinux.
move out of main namespace
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|## page was renamed from ProactiveSecurityRoadmap|
Proactive Security Roadmap
Malone Bug: BR
Establish a strategy for implementing proactive security features in Ubuntu.
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.
Data Preservation and Migration
Does not apply here.
Provide a grsecurity kernel in universe, if a community member is interested to care about it; [http://email@example.com/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.
Prelinked applications leave a huge /var/log/prelink.log which contains memory address; patch prelink to not dump addresses.
- 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. Mainstream (gcc 4.1, the developement branch) integrated stack smashing protections. When gcc 4.1 will become the standard Ubuntu compiler, would be worth to activate this option for most packages compilation.
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.).
- Status: Implemented in Breezy, patch sent to Debian.
- OpenBSD has a modified (with privsep and the like) and well audited version of dhclient and dhcpd. Could be of use for a comparison.
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.
- Status: Implemented in Breezy, patch sent to Debian.
- 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.
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.
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.
As of now, mainstream gcc development branch (4.1) implemented this protection (not mudflap). See [http://gcc.gnu.org/gcc-4.1/changes.html Gcc 4.1 changes]
- 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. It should be noticed that Secure Computing recently reaffirmed his patent right on SELinux "Type Enforcement" technology. They allow to use SELinux freely on anything but firewalls, vpn and authentification servers etc. See [http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf SSC Statement of assurance] and [http://lwn.net/Articles/6267/ LWN article]. What's our position in regard to this patent ?
Evaluate RSBAC or GRsecurity as potentials SELinux alternatives for ACL. See. [http://gentoo-wiki.com/Access_Control_Comparison_Table Gentoo's ACL Comparison Table]
ColinWatson: I think other-user-process hiding should be off by default; when turned on, it requires the system administrator to use extra privilege to inspect the state of the system, which is not necessarily an obvious security win.
FurryBall: I would like to comment on the SSP and userland protection part. In overall there are more effective and secure ways to achieve this - doing it by the kernelland governing the userland. Mentioning PAX and Exec_shield. I'd say do the task once and focus on doing it better there..
Input from JohnMoser
In PaX/ES (see PaXvExecShield for a dedicated wiki entry), it should be noted that Exec Shield most basically emulates (almost but not quite accurately) an NX bit on x86, and supplies very minimal address space layout randomization. This means that ES intrinsically weaker, meaning that maybe not now, but possibly in the future things COULD pop up that are exploitable under ES; and brute forcing ES is much easier, not only being short period but also being a realistically attackable period with proper brute force deterrance.
Exec Shield also leaves the program to define and enforce its own security; the program decides if it will have writable/executable pages, if it can generate its own code, and when and where to do so. In contrast, PaX leaves the burden of deciding on a policy to the system administrator, like SELinux does; and it leaves the kernel to enforce this policy. The administrator can make GrSecurity, RSBAC, or SELinux policies that control PaX restrictions, or even simply alter a field in the ELF header if there is no MAC; and the kernel will prevent the program from violating this policy by denying it requests for W|X memory or for transitions from !X->X. This is analogous to giving a user password guidelines (ES) versus having PAM run password changes not made by the sysadmin through cracklib and refusing to change the password if it doesn't hold up (PaX); one obviously works better because it doesn't rely on the fantasy that everyone is going to do what they're supposed to.
PaX also doesn't directly stop buffer overflows. Using PaX with ProPolice is a defense-in-depth solution which produces a stronger model of security. In addition to preventing code injection, ProPolice prevents the corruption of local variables. This means that potentially an attacker may be stopped from i.e. overwriting int passwd_svr_ip and having a password forwarded to him before the program crashes (rediculous, unlikely, but we've closed the possibility at this point so who cares). Combining this with LibSafe (which must be integrated into glibc in a multilib environment or multilib breaks horridly) produces a more robust protection as well, because the more common functions used for overflow won't be able to damage data outside the current stack frame; ProPolice doesn't protect this data, only data inside the current frame.
It would be easier for ProPolice to get into mainstream gcc with support from a major distribution. Although Gentoo always provides ProPolice with their gcc, pretty much only the handfull of devs in the Hardened herd are that excited about it. Some of the other devs have gone as far as to attack ProPolice, calling it a "dirty hack" and saying that a better solution is to just fix security holes without even trying to protect against them in the interim. OpenBSD also cornerstones on ProPolice, along with other technologies. Needless to say, ProPolice is well tested and simply needs a push into mainline; there has been [http://gcc.gnu.org/ml/gcc/2004-10/msg00823.html talk indicating that the gcc devs would be receptive] if it was more courteously presented. Etoh tends to just throw it out there. The Ubuntu devs could bridge that gap, in the better interest of the community of course.
GrSecurity has a good brute force deterrance scheme, which makes fork() block for 30 seconds when called if a PaX kill or segmentation fault is encountered in a child fork() process. This causes one fork() to occur every 30 seconds. As expected, this is a hugely visible denial-of-service attack; but hey, we're making broken code safe, it's not going to be pretty so don't try. Obviously this DoS can only occur if an already existing security hole is attacked, so clean programs are unaffected.
GrSecurity also supplies the mentioned OpenWall patch to cover world-writable +t directory symlink behavior and hardlink restrictions. In fact GrSecurity supplies a lot of useful things that should probably be taken into account. This doesn't mean that Ubuntu needs to use gradm2 instead of SELinux if the devs chose to implement much of GrSecurity.