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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Humble Hacker?
- The US Government and Open-Source Software
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide