Analysis of the [WWW] Ubuntu Linux Security Notices done by JohnMoser. This is not a professional analysis, just a statistics measurement to help back up the desire for better ProactiveSecurity.

Analysis up through USN #60-1

Types of Vulnerabilities

NOTE: Some USNs are "Multiple Vulnerabilities." These may contribute to multiple categories; or may supply multiple vulnerabilities from a given category. USNs supplying multiple vulnerabilities from a given category (for example, 5 buffer overflows) are counted as 1, because most of them are not clear on exactly how many.

Integer Overflows: 5 (8.3%)

Buffer Overflows: 27 (45.0%)

Race/tmpfiles: 11 (18.3%)

Race/non-tmpfiles: 1 (1.7%)

Bad malformed (not excessively long) data handling: 7 (11.7%)

Lack of environment checks: 2 (3.3%)

Old Fashioned Generic Bugs(TM) and Bad Design(TM): 5 (8.3%)

Kernel/generic: 5 (8.3%)

Kernel/Buffer Overflow: 1 (1.7%)



(Second level bullets above should just be indented, wtf? indentation just makes one big paragraph in a bullet)


Line Noise

Here's some extra stuff to consider.

Access Control

For those vulnerabilities left active, containment should be appropriate. The efforts to implement an SELinux policy for Ubuntu should continue; an appropriate policy to properly sandbox each start-up service and give sysadmin_t to root logins using login/su may be workably transparent to home users, since root would act as expected. Compromises could still do damage; but the SELinux policy would constrict that damage, in the same way that the DAC constricts a compromise in a normal user account. For example, apache/mod_php may be compromised and used to deface hosted user pages or a hosted web site; however, it cannot destroy anything in /usr or /lib or /bin or /sbin, and so cannot deploy a rootkit.

Within the constrictions, compromises may still be disasterous. This depends highly on the implementation and the policy. If the implementation requires the compromised service to interact with a database of medical data or credit card info, a serious leak or destruction of Confidential Information could occur. A worst case scenario would be access through a process with write access to medical data, which could be a life-threatening compromise. Still, a proper MAC policy may be able to protect such data when other countermeasures can not, such as when a neighboring process in the same account but with a different job is compromised, yet has no access to that particular set of data.

The sudo program is a special case; compromise of a no-password sudo user or an account which has sudo caching the password would be hazardous, and so the security implications of allowing sudo to get sysadmin_t at all should be examined. Users can always sudo bash and then activate sysadmin_t.

The implementation of an SELinux policy is something that needs serious consideration. When installing foreign programs, there may be no policy for them; in such a case, they may be unusable by anyone. Thus, SELinux should be an option, and an easy to disable one from a documented security administrator account, or from root on a non-SELinux kernel. A boot option with "enforcing=0" or "selinux=0" should disable it as well; although including such an option should be optional.

Boot Loader Control

Grub can handle md5 passwords. The option to set a password to prevent booting such entries and to prevent command line editing in grub would be good as well. If memory serves, a grub entry will halt at a "lock" command and demand a password to continue. Thus:

password --md5 $aa$aaaaaaaaaaaaaaa 

title Ubuntu Linux
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1
initrd /boot/initrd.img

title Ubuntu Linux [SELinux softmode]
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1 enforcing=0
initrd /boot/initrd.img

title Ubuntu Linux [SELinux Disabled]
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1 selinux=0
initrd /boot/initrd.img

The above will disable the 'e' (edit entry) and 'o' (open new entry) commands in grub, forcing a user to use one of the existing entries. It will also prevent the user from booting with SELinux in softmode or disabled. A user would need to use the 'p' command and then enter the proper password to enable these features.

last edited 2005-07-31 09:03:24 by CoreyBurger2