moved attic to a branch of it's own

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.
-