Linux 2.2 and the Frame-Buffer Console
Thus far, I have managed to not even mention the role frame-buffers play in current Linux kernels. The frame-buffer console system has been a staple of several other UNIX systems for quite some time and several Linux flavors, in particular Linux/m68k and Linux/PPC. The issue on those platforms that made the frame-buffer console so important is a simple one: not all video hardware supports a built-in text-mode. On these systems, the frame-buffer console is not a new luxury which brings up a boot logo, but rather a requirement for functionality. On these systems, the picture is a tad different. They still have X, of course, and X is an excellent way of creating applications in a device-independent fashion. A special X server designed specifically for dealing with frame-buffer systems has nearly always been available. The picture on those systems is also simplified, since no library is available that would enable them to run SVGALib applications.
Under the current implementation, a number of security concerns must be raised when dealing with the graphics subsystem. It is partly because of these security implications that the frame-buffer console has become a part of the Linux 2.2 kernel.
Hardware access to user programs must be provided through a kernel API which provides a layer of device abstraction. To keep the system secure and crash-free, the kernel interface must be carefully designed, as it is within the kernel that the most damage can be done. Access to hardware is dangerous; it would be quite easy to crash the machine if a user program could access it directly. Also, badly designed kernel interfaces could reveal sensitive data about a user, breaches of security, no matter how difficult to exploit, are taken very seriously in the Linux developer community. While no kernel provisions exist for direct hardware access, there are certain workarounds which can be used to circumvent these restrictions—in a way that is as secure as possible.
There are two exceptions to the “no direct access” rule. The first is simple: with programs run by root, the system administrator (who should generally know what she is doing) can access any files and any hardware directly. In fact, there are virtually no limitations as to what root can do. But you certainly don't want your users having the root password and using it each time they want to run Quake, do you? The second exception is the solution to this issue: the owner of a program (generally root) can set a flag called the “setuid bit” (Set User ID) on a program, allowing regular users to “be” the other user as far as the program is concerned. Thus, if root owns the file and it has the setuid bit set, that program will always have root access and therefore will always be able to access hardware directly. In this special and well-controlled case, end users can run their Quake or their X servers despite the fact that they normally wouldn't be able to access the hardware directly.
Note, however, that not all graphical programs will need to be “setuid root” to operate. X programs in particular do not access any hardware directly. Rather, they communicate to the X server via an API which then translates what they want to do onto the video hardware. SVGAlib applications, in contrast, generally all need to have special permissions to operate properly.
The security implications of having an arbitrary program run as root should be obvious. Linux does not currently have a method of saying that a particular program can “just” access any file or “just” access hardware directly—work is progressing in this area. Instead, a “setuid root” application can do anything, including shutting down the server. Talk about a denial of service! Thus, these applications must be very carefully written so that an errant user cannot do anything that would violate the security of the box. It is up to the administrator of the site to maintain and ensure these special programs are used only when absolutely necessary, otherwise gaping security holes will result.
Even a carefully written program can sometimes be cracked via “stack smashing” to gain root access if a programmer does not make sure to watch his buffers and use safer routines like strncpy instead of strcpy. In general, programmers who write “setuid root” applications should be aware of any buffers used throughout the program. For the record, strcpy and strncpy are both functions that copy text data (strings) from place to place in memory. The “n” in strncpy means there is a maximum number of characters to be copied. Otherwise, it would be possible for a cracker to manipulate data in such a way that the data being copied is larger than the place to which it is copied and the excess would overwrite memory. If they are skilled, this excess could include program code which would then be run to break into a shell or do other damage—and it would be executed as root.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development