| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
capp-lspp-config: privilege escalation
| Package(s): | lspp-eal4-config-ibm, capp-lspp-eal4-config-hp | CVE #(s): | CVE-2008-0884 | |||
| Created: | April 1, 2008 | Updated: | April 2, 2008 | |||
| Description: | The lspp-eal4-config-ibm and capp-lspp-eal4-config-hp packages contain
utilities and documentation for configuring a machine for the Controlled
Access Protection Profile, or the Labeled Security Protection Profile.
It was discovered that use of the "capp-lspp-config" script results in the "/etc/pam.d/system-auth" file being set to world-writable. Authorized local users who have limited privileges could then exploit this to gain additional access, or to escalate their privileges. | |||||
| Alerts: |
| |||||
(Log in to post comments)
capp-lspp-config: privilege escalation
Posted Apr 3, 2008 10:35 UTC (Thu) by pjm (subscriber, #2080) [Link]
lol. There's a lesson here somewhere, about the value/dangers of “adding security” to a system.
capp-lspp-config: privilege escalation
Posted Apr 7, 2008 15:23 UTC (Mon) by kweidner (subscriber, #6483) [Link]
Yes, the bug is of course embarrassing - but it's a good example of an unrelated change breaking something that was working fine for years (see the issue description for more details) due to potentially unsafe defaults in a common tool. The stat(1) program should probably follow symlinks by default...Just to address a common misunderstanding - the goal of the configuration script was not "adding security", it sets up a specific system configuration that matches the requirements of the protection profiles (CAPP, LSPP, and RBACPP) as documented in the security target and that matches the one which was tested and evaluated.
The configuration package provides a kickstart script to automate the installation (including package selection), and runs a postinstall script to change some configuration settings (including the PAM config files), create the initial admin accounts, and make some other mostly minor changes to meet the protection profile requirements.
The intended result of the procedure is that you'll end up with a system configured in MLS (multilevel security) mode that matches the configuration that was evaluated, and that is ready for further customization for the site. It's not intended to be more secure than a normal installation, the point is to avoid the very many error-prone manual steps that would be involved in setting this up manually.