1
MusE Security Information
2
=========================
4
In order to operate reliably at low latencies, MusE needs root privileges.
5
For a stand-alone computer in a home environment, this is not a problem.
6
However, on networked machines with multi-user access, there are some security
10
Why does MusE require root privileges ?
11
---------------------------------------
14
MusE must set the real time clock (/dev/rtc/) to a higher rate in order to get
15
a more precise timing source than the standard setting would allow.
16
For this task, it is *not* sufficient to alter the permissions or group of
17
/dev/rtc. You need root access.
20
The MusE audio threads must acquire real-time scheduling to perform with low
21
latency and free of dropouts. Since this could be misused for a local
22
denial-of-service attack (you can hog 100% cpu with a real-time task, thus
23
effectively making the system unusable), only root is allowed to do that.
26
Do I need to be root to run MusE ?
27
----------------------------------
29
No. You should not do normal work as root. Use the root login exclusively for
30
administrative tasks. You can run MusE as a normal user, provided you have set
32
This is done automatically when you build and install MusE.
35
How does this "suid bit" thing work ?
36
--------------------------------------
38
Normally, when a program is started, it gets the user and group id of the user
39
who started it, and thus has the same permissions as the user. It can read and
40
write the same files and use the same devices.
42
Some applications need higher privileges to perform certain tasks, but must be
43
available to normal users. To accomplish this, UNIX-like systems have the
44
concept of the "effective user id".
46
That means you can start a process, but the effective user id will be someone
47
else's, most likely that of the root user. You can recognize such programs by
48
the suid (for set-user-id) bit in their permissions.
50
For example, when you do
54
you will see something like
56
-rwsr-xr-x 1 root root 20908 Feb 27 2001 /bin/ping .
58
This tells you it's a normal file (the first dash), it is readable and writable
59
by the owner (root) and has the owner's suid bit set (the letter "s").
60
You may invoke it as a normal user, but the program will have root permissions
63
(Btw, there is also an sgid (set-group-id) bit, which allows a program to be run
64
with the permissions of the group it is owned by. This can be used for
65
finer-grained access control to some programs but is rarely used in practice.)
67
(Btw2, the letter "s" actually means both "executable" AND "set-{user,group}-id".
68
A capital "S" stands for "set-uid" without the execution privilege, which also
69
very rarely seen on real systems.)
72
What is the problem with suid programs ?
73
----------------------------------------
75
suid programs are safe as long as you can be sure they do only the job they were
76
written to do. For instance, you certainly want users to be able to do a ping,
77
but you wouldn't want them to wipe out the system disk while doing it.
79
Unfortunately, there is a very common vulnerability in many programs called a
80
buffer overflow, which allows an attacker to spawn a shell from within a suid
81
program that inherits the permissions, giving him or her root access to the
83
This exploit is fairly easy for an experienced attacker. All that's needed is
84
the compiled equivalent of the C expression execve("/bin/sh"), which can be
85
inserted into the running program whenever it does not check the length of user
86
input properly, by overflowing a buffer and thus overwriting a part of
87
the program code with the shell exploit code.
89
The more complex a program becomes, the more likely buffer overflow
90
vulnerabilities slip in.
92
If you are interested in details of such attacks, I recommend AlephOne's paper
93
"Smashing the stack for fun and profit", to be found in Issue 49 of Phrack
94
Magazine (http://www.phrack.com/show.php?p=49&a=14).
97
Does MusE have buffer-overflow vulnerabilities ?
98
------------------------------------------------
100
It may. But even if it had not, it is good practice to assume it does.
101
As soon as you are in a security-critical environment, you should treat all suid
102
programs with extra care unless they are proven to be secure.
104
This is a gruesome and boring task, and we all want Werner to concentrate on
105
cool new features rather than digging through the code to fix loopholes that
106
aren't even a problem for 99% of the MusE users.
107
MusE does not need to be as secure as server daemons. It is intended for home
108
use in a trusted environment.
109
If you run MusE on your company's primary DNS server, it's your fault.
111
But even home machines can become targets for intruders the moment they connect
112
to the internet. Since almost all of the machines than run MusE are occasionally
113
used to surf the web, it might be worth taking a few precautions.
116
What can I do to minimize the risk of a suid program ?
117
------------------------------------------------------
119
By default, Werner drops the root privileges in MusE's GUI thread - only the
120
audio threads keep it. This rules out many possible exploits, since GUI code is
121
usually the hardest to make secure.
124
As a further very simple yet effective security precaution, you can create a
125
group of trusted users, and give only this group access to critical suid
126
programs. For example, you might create a group called musers, of which you and
127
your best friend are members. Then you can set the muse binary as follows:
129
#chown root:musers muse
132
-rwsr-x--- 1 root musers 20930049 Aug 28 19:34 muse
134
Now only members of the group musers can use MusE, Joe Random Hacker can not.
135
(However, if your account is hacked, MusE can then be exploited to gain root,
138
Additionally, you can use "givertcap" as described in the next section.
141
What is givertcap and how do I use it ?
142
---------------------------------------
144
"givertcap" (give real-time capabilites) is a small wrapper written by Tommi
146
When enabled, it is executed by MusE and gives to it just the capabilities
147
needed to set the timer and get real-time scheduling, but not the full set of
148
root privileges. This greatly reduces the amount of damage that can be done.
150
However, it is not used by default, since it requires a kernel modification.
152
To enable givertcap, simply call ./configure --enable-rtcap before compiling.
153
(The givertcap code is part of the MusE distribution.)
155
With current kernels, you need to apply a little patch to the kernel headers:
156
Go to /usr/src/linux/include/linux (or wherever you have your kernel sources)
157
and in the file capability.h change the line
159
#define CAP_INIT_EFF_SET to_cap_t(~0&~CAP_TO_MASK(CAP_SETPCAP))
161
#define CAP_INIT_EFF_SET to_cap_t( ~0 )
165
#define CAP_INIT_INH_SET to_cap_t(0)
167
#define CAP_INIT_INH_SET to_cap_t( ~0 )
170
You must then recompile your kernel.
172
In this setup, givertcap must be set suid root, but MusE can be run with normal
174
Now all possible suid exploits described above apply to givertcap, but since it
175
is such a tiny program, it can be checked for exploits far more easily and can
176
be considered reasonably secure.
178
Unfortunately, givertcap can be used to grant real-time privileges to *any*
179
program, so it's an easy way to have the machine clogged up by a malicious user
180
who might run bogus tasks at 100% system usage.
181
Therefore, you *must* create an extra group for it (called "musers" in this
183
# chown root:musers givertcap
184
# chmod 4750 givertcap
185
Do not forget to remove the suid bit on muse afterwards by doing
189
For more information about givertcap and kernel capabilites, see
190
http://www.tml.hut.fi/~tilmonen/givertcap/
192
http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.
200
General Linux system security:
201
http://linuxdoc.org/HOWTO/Security-Quickstart-HOWTO/
202
http://linuxdoc.org/HOWTO/Security-HOWTO.html
204
Secure Linux programming:
205
http://linuxdoc.org/HOWTO/Secure-Programs-HOWTO/
212
http://www.tml.hut.fi/~tilmonen/givertcap/
214
An alternative approach, using a kernel module:
215
http://arctrix.com/nas/linux/capwrap.tar.gz
218
http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.
221
Adding capability flags to ELF files:
222
http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html
225
Buffer Overflow attacks:
226
"Smashing the stack for fun and profit" by AlephOne 1996, published in
227
Phrack magazine, issue 49
228
http://www.phrack.com/show.php?p=49&a=14
230
In the MusE source, app.cpp contains the invocation of givertcap and the
231
dropping of the suid privileges: grep for "getCapabilities" and "setuid" to see
234
________________________________________________________________________________
237
This document was written by J�rn Nettingsmeier
238
<nettings@folkwang-hochschule.de>
239
Corrections and improvements welcome.
241
Thanks to Werner Schweer and Tommi Ilmonen for answering my questions.
243
Last updated 02/22/2002.
added
removed
SECURITY
