Root for All on the SE Linux Play Machine
When the play machine had been on-line for less than a day, a user reported that /etc/shadow could be read. This directory was declared to be outside the scope of the LinuxTag demonstration, but I should have fixed it before putting the machine on-line. I changed the shadow file to have the type shadow_t, which required changes to the spasswd wrapper program and the SE policy for it.
Adding full support for shadow_t was difficult because, in many instances, the same program changes /etc/passwd and /etc/shadow by re-creating them, thus giving them the default context of etc_t. I could have modified those programs to use the open_secure(2) system call to specify the security context at file creation time. I decided not to, however, because it would involve a lot of work on security critical applications, creating the risk that an error might weaken security. Instead, I wrote wrapper code to run those programs and set /etc/passwd back to etc_t after the program exits. I also made shadow_t the default type for those programs when creating files in /etc. Still, even when /etc/shadow had the type etc_t, it prevented unauthorized root users from writing to it. It was read-only to root users in the user_t domain.
The next day, someone discovered that /dev/nvram was not adequately protected. It was writable by everyone, therefore any user could make the machine unbootable by scrambling the BIOS setting. Potentially, they could have made the Qube BIOS pass different parameters to the kernel to weaken security on the next boot. The Cobalt BIOS performs the functions that a bootloader such as LILO would perform on other machines. I changed the policy to fix that glitch immediately. It is important to note that different platforms, either different CPU architecture or a different hardware, may require similar minor changes to the security policy to match different device nodes in /dev. With the current policy there is little risk of this causing insecurity, as the default is to deny most operations related to device nodes.
Some people were concerned that I had not appropriately granted authorization and wanted reassurance that they were not doing anything illegal, so I changed the /etc/motd to state that the machine was put on-line for the purpose of security testing. I explained that it would be acceptable to break the security in any way, including methods that may render the machine unusable, as long as I was informed of the method used. I also stated that it was not to be used for launching attacks on other machines, although I tried to make that impossible with firewall rules. Finally, I requested that no one try denial-of-service (DoS) attacks, as they are boring and that is not the aim of the exercise.
From June 20 on, the operation of the play machine was fairly uneventful. In February 2003, I put a play machine on-line at the Debian stand at OSDEM and announced it as a capture the flag contest. This received a surprising amount of interest; at times there were up to 30 people watching one person trying to crack the security. A user managed to get the easy flag, accessing a file in a specified non-root account after logging in as root. He did this by setting the EDITOR environment variable and running crontab -e. The crontab program ran the editor with more SE privileges than a regular program and allowed greater access. Even though the exploit would not work in a typical server configuration, because you don't give untrusted users root access even if you are running SE Linux, I changed the policy for the crontab program to prevent doing so. Even with this, the crontab attack still was confined to a single user role. Therefore, any accounts that were in different domains, such as the one I used for running the play machine, could not be touched.
One ongoing problem I experienced was that of resource usage. Many users thought they had achieved something by filling the filesystem or running the machine out of other resources. The message about DoS attacks didn't seem to receive much notice.
Another interesting problem I had was trying to convince users they actually were root. I had GCC installed, and many users compiled their own versions of ps and other utilities in the belief that they weren't really root and that it was all a trick with modified utilities. One user even had assembly code to call the getuid() system call to determine whether I had modified libc6. Although that user really was root, it would be a fun exercise to modify libc6 to pretend that someone had logged in as root when they really had not. I encourage readers to try this out for themselves.
Of course, not all users were so difficult to convince. I gave the password to a “black hat” person who was seeking machines for the installation of a rootkit. He tried installing his rootkit but found that all the relevant directories (/bin, /sbin and /etc) and the files they contained were not writable. He asked for assistance in installing, but I was unable to help him.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Reply to comment | Linux Journal
4 min 31 sec ago
- Poul-Henning Kamp: welcome to
2 hours 14 min ago
- This has already been done
2 hours 15 min ago
- Reply to comment | Linux Journal
3 hours 50 sec ago
- Welcome to 1998
3 hours 49 min ago
- notifier shortcomings
4 hours 13 min ago
5 hours 49 min ago
- Android User
5 hours 51 min ago
- Reply to comment | Linux Journal
7 hours 44 min ago
10 hours 34 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?