~ubuntu-branches/ubuntu/quantal/muse/quantal

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.