diff options
Diffstat (limited to 'attic/muse2-oom/muse2/SECURITY')
| -rw-r--r-- | attic/muse2-oom/muse2/SECURITY | 244 |
1 files changed, 0 insertions, 244 deletions
diff --git a/attic/muse2-oom/muse2/SECURITY b/attic/muse2-oom/muse2/SECURITY deleted file mode 100644 index e0fa68a5..00000000 --- a/attic/muse2-oom/muse2/SECURITY +++ /dev/null @@ -1,244 +0,0 @@ -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 -<nettings@folkwang-hochschule.de> -Corrections and improvements welcome. - -Thanks to Werner Schweer and Tommi Ilmonen for answering my questions. - -Last updated 02/22/2002. - |