MusE Security Information ========================= In order to operate reliably at low latencies, MusE needs root privileges. For a stand-alone computer in a home environment, this is not a problem. However, on networked machines with multi-user access, there are some security issues to be aware of. Why does MusE require root privileges ? --------------------------------------- 1. MusE must set the real time clock (/dev/rtc/) to a higher rate in order to get a more precise timing source than the standard setting would allow. For this task, it is *not* sufficient to alter the permissions or group of /dev/rtc. You need root access. 2. The MusE audio threads must acquire real-time scheduling to perform with low latency and free of dropouts. Since this could be misused for a local denial-of-service attack (you can hog 100% cpu with a real-time task, thus effectively making the system unusable), only root is allowed to do that. Do I need to be root to run MusE ? ---------------------------------- No. You should not do normal work as root. Use the root login exclusively for administrative tasks. You can run MusE as a normal user, provided you have set the *suid bit*. This is done automatically when you build and install MusE. How does this "suid bit" thing work ? -------------------------------------- Normally, when a program is started, it gets the user and group id of the user who started it, and thus has the same permissions as the user. It can read and write the same files and use the same devices. Some applications need higher privileges to perform certain tasks, but must be available to normal users. To accomplish this, UNIX-like systems have the concept of the "effective user id". That means you can start a process, but the effective user id will be someone else's, most likely that of the root user. You can recognize such programs by the suid (for set-user-id) bit in their permissions. For example, when you do #ls -l /bin/ping you will see something like -rwsr-xr-x 1 root root 20908 Feb 27 2001 /bin/ping . This tells you it's a normal file (the first dash), it is readable and writable by the owner (root) and has the owner's suid bit set (the letter "s"). You may invoke it as a normal user, but the program will have root permissions while it runs. (Btw, there is also an sgid (set-group-id) bit, which allows a program to be run with the permissions of the group it is owned by. This can be used for finer-grained access control to some programs but is rarely used in practice.) (Btw2, the letter "s" actually means both "executable" AND "set-{user,group}-id". A capital "S" stands for "set-uid" without the execution privilege, which also very rarely seen on real systems.) What is the problem with suid programs ? ---------------------------------------- suid programs are safe as long as you can be sure they do only the job they were written to do. For instance, you certainly want users to be able to do a ping, but you wouldn't want them to wipe out the system disk while doing it. Unfortunately, there is a very common vulnerability in many programs called a buffer overflow, which allows an attacker to spawn a shell from within a suid program that inherits the permissions, giving him or her root access to the entire system. This exploit is fairly easy for an experienced attacker. All that's needed is the compiled equivalent of the C expression execve("/bin/sh"), which can be inserted into the running program whenever it does not check the length of user input properly, by overflowing a buffer and thus overwriting a part of the program code with the shell exploit code. The more complex a program becomes, the more likely buffer overflow vulnerabilities slip in. If you are interested in details of such attacks, I recommend AlephOne's paper "Smashing the stack for fun and profit", to be found in Issue 49 of Phrack Magazine (http://www.phrack.com/show.php?p=49&a=14). Does MusE have buffer-overflow vulnerabilities ? ------------------------------------------------ It may. But even if it had not, it is good practice to assume it does. As soon as you are in a security-critical environment, you should treat all suid programs with extra care unless they are proven to be secure. This is a gruesome and boring task, and we all want Werner to concentrate on cool new features rather than digging through the code to fix loopholes that aren't even a problem for 99% of the MusE users. MusE does not need to be as secure as server daemons. It is intended for home use in a trusted environment. If you run MusE on your company's primary DNS server, it's your fault. But even home machines can become targets for intruders the moment they connect to the internet. Since almost all of the machines than run MusE are occasionally used to surf the web, it might be worth taking a few precautions. What can I do to minimize the risk of a suid program ? ------------------------------------------------------ By default, Werner drops the root privileges in MusE's GUI thread - only the audio threads keep it. This rules out many possible exploits, since GUI code is usually the hardest to make secure. As a further very simple yet effective security precaution, you can create a group of trusted users, and give only this group access to critical suid programs. For example, you might create a group called musers, of which you and your best friend are members. Then you can set the muse binary as follows: #chown root:musers muse #chmod 4750 muse #ls -l muse -rwsr-x--- 1 root musers 20930049 Aug 28 19:34 muse Now only members of the group musers can use MusE, Joe Random Hacker can not. (However, if your account is hacked, MusE can then be exploited to gain root, but hey...) Additionally, you can use "givertcap" as described in the next section. What is givertcap and how do I use it ? --------------------------------------- "givertcap" (give real-time capabilites) is a small wrapper written by Tommi Ilmonen. When enabled, it is executed by MusE and gives to it just the capabilities needed to set the timer and get real-time scheduling, but not the full set of root privileges. This greatly reduces the amount of damage that can be done. However, it is not used by default, since it requires a kernel modification. To enable givertcap, simply call ./configure --enable-rtcap before compiling. (The givertcap code is part of the MusE distribution.) With current kernels, you need to apply a little patch to the kernel headers: Go to /usr/src/linux/include/linux (or wherever you have your kernel sources) and in the file capability.h change the line #define CAP_INIT_EFF_SET to_cap_t(~0&~CAP_TO_MASK(CAP_SETPCAP)) to #define CAP_INIT_EFF_SET to_cap_t( ~0 ) and the line #define CAP_INIT_INH_SET to_cap_t(0) to #define CAP_INIT_INH_SET to_cap_t( ~0 ) . You must then recompile your kernel. In this setup, givertcap must be set suid root, but MusE can be run with normal privileges. Now all possible suid exploits described above apply to givertcap, but since it is such a tiny program, it can be checked for exploits far more easily and can be considered reasonably secure. Unfortunately, givertcap can be used to grant real-time privileges to *any* program, so it's an easy way to have the machine clogged up by a malicious user who might run bogus tasks at 100% system usage. Therefore, you *must* create an extra group for it (called "musers" in this example): # chown root:musers givertcap # chmod 4750 givertcap Do not forget to remove the suid bit on muse afterwards by doing # chmod 755 muse . For more information about givertcap and kernel capabilites, see http://www.tml.hut.fi/~tilmonen/givertcap/ and http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2. txt. Further reading: ================ General Linux system security: http://linuxdoc.org/HOWTO/Security-Quickstart-HOWTO/ http://linuxdoc.org/HOWTO/Security-HOWTO.html Secure Linux programming: http://linuxdoc.org/HOWTO/Secure-Programs-HOWTO/ Permissions: man chmod man chattr givertcap: http://www.tml.hut.fi/~tilmonen/givertcap/ An alternative approach, using a kernel module: http://arctrix.com/nas/linux/capwrap.tar.gz Kernel capabilites: http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2. txt Adding capability flags to ELF files: http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html Buffer Overflow attacks: "Smashing the stack for fun and profit" by AlephOne 1996, published in Phrack magazine, issue 49 http://www.phrack.com/show.php?p=49&a=14 In the MusE source, app.cpp contains the invocation of givertcap and the dropping of the suid privileges: grep for "getCapabilities" and "setuid" to see how it's done. ________________________________________________________________________________ This document was written by Jörn Nettingsmeier Corrections and improvements welcome. Thanks to Werner Schweer and Tommi Ilmonen for answering my questions. Last updated 02/22/2002.