Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
Jan Buchal napsal(a): HG Hi, What is the need for speech-dispatcher to run as root? Is it HG possible to run it as non-root? We need to modify the HG speechd.conf files from a non-root program and as such run the HG speech-dispatcher daemon with non-root privileges. Sure. SD can runs as root or as any other user which has access on audio. Every user has own configuration in .speech-dispatcher directory or if there no, then it search in /etc/speech-dispatcher Hello, the various ways of running Speech Dispatcher are described in http://www.freebsoft.org/doc/speechd/speech-dispatcher_9.html#SEC22 Even when running as a system-wide service, it is recommended not to run Speech Dispatcher under root, but under some special user like 'speech-dispatcher' who has only access to the appropriate log/config/pid destinations and to the audio hardware for the security reasons mentioned above. I think the Debian package for Speech Dispatcher is a good example. With regards, Hynek Hanke ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
HG == Hemant Goyal [EMAIL PROTECTED] writes: HG Hi, What is the need for speech-dispatcher to run as root? Is it HG possible to run it as non-root? We need to modify the HG speechd.conf files from a non-root program and as such run the HG speech-dispatcher daemon with non-root privileges. Sure. SD can runs as root or as any other user which has access on audio. Every user has own configuration in .speech-dispatcher directory or if there no, then it search in /etc/speech-dispatcher -- Jan Buchal Tel: (00420) 24 24 86 008 Mob: (00420) 608023021 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
Hi James, The point I was trying to make was that the Sugar API itself could have removed the burden of setting these options from the developer. Yes that is indeed what is happening :). And there is no API call involved whatsoeverl with the present design :). Perhaps once the code is released you'll get an idea whats exactly happening. An Activity could also, using the API, find out what the default values are without having to look at speechd.conf. I think it would be useful for the activity developer in certain instances to get the default speech synthesis settings. I'll look into this requirement and see if we can provide some methods through sugar for this purpose. Or the Sugar Activity base class could automatically start up a speech client and give the Activity developer simple methods to use it in his application, or even automatically speech enable any Activity so that for instance the contents of the control with the focus could be spoken, or whatever it is that screen readers for the blind do. Well, the main reason why sugar does not/should not handle requests for speech-synthesis from all Activities is that we will need to re-write a lot of code to handle priorities/serializing speech synth requests from multiple activities/maintaining Activitiy-specific settings (these were issues with the initial DBUS API that we created, and the main reason for shifting to speech-dispatcher). All these features are already available in speech-dispatcher and hence communicating directly with the speech-dispatcher server instead through sugar seems more optimal. Also if Activities had to connect to a client that was started by sugar would mean that sugar will have to provide the Callbacks that are at present returned by speech-dispatcher directly to the Activity. Thats why its best that Activities connect themselves to speech-dispatcher and not communicate through sugar. Automatically speech-enabling an activity is something I will be exploring, however, from initial analysis its not that straight forward. How sugar will hack into Activities and pull the data relevant for speech-synth is what needs to be analyzed for this purpose. I understood that the Sugar developers wanted to provide text to speech support to all Activities, even those written before TTS was available. To do that you would have to change the Sugar base classes, etc. anyway. Are you suggesting that just like the Activity Tool bars etc are provided to Sugar Activities primitively, speech-synth should be provided primitively when each Activity starts? Cheers! Hemant ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
P.S. - In the long run, speechd should probably learn to run under its own uid(s). Then the appropriate uids can own the appropriate log files. I agree with Michael here. If you look at some of the files in /var/run and /var/log, you will see that some of them are owned by a specific user representing the binary that logs to those files/directories. Sometimes, they may be owned by root, but in a group specific to the application with group write permissions. Creating a standard user for an application is normal practice on many GNU/Linux distros. I've seen the set gid bit set on directories so that any files created in that directory are created in the same group as the directory regardless of the uid of the creating process e.g. chmod g+s dirname The other alternative I've seen, but which I don't think is as good, is to put the logs in /tmp. The main downside here is that the /tmp directory is often cleaned out as part of the boot or shutdown process. this can cause valuable logging information to be lost right when you need it e.g. speech stopped working and the only easy way to get it back was a reboot, but now you have lost any logging that could be used for diagnostic purposes. In some cases, logging to /tmp can represent a security issue, but I'm not sure if that is relevant in this case and at any rate, it would still be less of a security issue than running as root using suid. regards, Tim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
running speech-dispatcher as non-root using setuid on XO and accompanying security issues
Hi, What is the need for speech-dispatcher to run as root? Is it possible to run it as non-root? We need to modify the speechd.conf files from a non-root program and as such run the speech-dispatcher daemon with non-root privileges. To solve the above problem I applied the setuid bits to the speech-dispatcher executable (and changed the permissions of the binary to 6711) and things have been rosy. However, I would like to ask whether using setuid is advisable in the OLPC laptop from a security point of view? i read using setuid should generally be avoided, however running speech-dispatcher as non-root is almost essential in our case. Looking forward to a reply. Thanks! Hemant ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
On Thu, Jul 17, 2008 at 04:04:05PM +0530, Hemant Goyal wrote: However, I would like to ask whether using setuid is advisable in the OLPC laptop from a security point of view? It is like putting a hole through a city wall into a house which is built against the wall, and then telling the city guards to stand outside the house as well as the city gate. Practical, very handy, but extends the safety barrier to include the setuid program code. It means the city guards need to trust the owner of the house. Because the house is a new attack vector. The walls of the house might be thinner than the city walls. It means the code that is running setuid has to be trusted. Because this new code is a new attack vector ... if it can be asked to open or write files, then it can attack a filesystem. I cannot comment on the relative importance of the OLPC security model and the speech-dispatcher needs. I imagine that would depend on a deployment. But I worry about hundreds of thousands of systems that might be infected via this setuid program, if it turns out to contain a flaw. I recall earlier discussion about it or something else. Is there a way to rewrite it to not require root? Almost every other activity does not require root, or obtains it through a carefully controlled mechanism via the kernel. Can you tell me what syscall fails if it is not root? strace may be helpful. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
Hi James,
It is like putting a hole through a city wall into a house which is
built against the wall, and then telling the city guards to stand
outside the house as well as the city gate.
Practical, very handy, but extends the safety barrier to include the
setuid program code.
It means the city guards need to trust the owner of the house. Because
the house is a new attack vector. The walls of the house might be
thinner than the city walls.
It means the code that is running setuid has to be trusted. Because
this new code is a new attack vector ... if it can be asked to open or
write files, then it can attack a filesystem.
Thanks for elaborating the problem in such simple words :). So we can
never tell what just might happen in case some nasty piece of codes
runs through the speech-dispatcher binary... Can't we test and sign
the binaries or something like that? I agree it will add to the burden
of carefully testing speech-dispatcher every time we use an updated
binary however.
I recall earlier discussion about it or something else. Is there a way to
rewrite it to not require root? Almost every other activity does not
require root, or obtains it through a carefully controlled mechanism via
the kernel.
Well sugar-control-panel is what runs as non-root and which would
modify the speech-dispatcher configuration files. Since I got the
setuid idea I have relocated the configuration files of
speech-dispatcher to /home/olpc/.speechd from /etc/speech-dispatcher.
Can you tell me what syscall fails if it is not root? strace may be
helpful.
[EMAIL PROTECTED] devel]$ /usr/bin/speech-dispatcher
Can't create pid file in /var/run/speech-dispatcher.pid, wrong permissions?
===
Strace Output:
open(/var/run/speech-dispatcher.pid, O_RDONLY) = 3
fcntl64(3, F_GETLK, {type=F_UNLCK, whence=SEEK_SET, start=1, len=3, pid=1}) = 0
close(3)= 0
unlink(/var/run/speech-dispatcher.pid) = -1 EACCES (Permission denied)
open(/var/run/speech-dispatcher.pid, O_WRONLY|O_CREAT|O_TRUNC, 0666)
= -1 EACCES (Permission denied)
write(2, Can\'t create pid file in /var/ru..., 76Can't create pid
file in /var/run/speech-dispatcher.pid, wrong permissions?
===
So I guess it s not able to write a PID file.
Next I tried to relocate where the PID file is written as follows:
[EMAIL PROTECTED] devel]$ /usr/bin/speech-dispatcher -P
/home/hemant/speechd.pid
Now it gets stuck at other locations. Its not able to open a
connection with ALSA and create a log file in/var/log/speechd.log.
==
Error: can't open logging file /var/log//speechd.log! Using stdout.
-(I can fix this error since its under my control through the RPM
package)
ALSA lib pcm_dmix.c:831:(snd_pcm_dmix_open) unable to create IPC semaphore
Thu Jul 17 17:10:26 2008 [648100] ALSA ERROR: Cannot open audio
device default (Permission denied)
Thu Jul 17 17:10:26 2008 [648175] ALSA ERROR: Cannot initialize Alsa
device 'default': Can't open.
==
The corresponding strace outputs are :
==
open(/var/log//speechd.log, O_WRONLY|O_CREAT|O_APPEND, 0666) = -1
EACCES (Permission denied)
open(/var/log//espeak.log, O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1
EACCES (Permission denied)
==
Thanks for the prompt reply :)
Best,
Hemant
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO
Hemant, I have some experience using speech-dispatcher and it seems to me that the XO really doesn't need to run speech-dispatcher any differently than any other computer does (other than getting rid of unnecessary dependencies of course). My understanding of what you want to do is that you want your contro,l panel to change the default settings in speechd.conf and restart speech-dispatcher so that all Activities that use speech will have these new default values to work with. To my mind doing this (if I understand you correctly) is like burning down your house to cook a pig. Speech-dispatcher lets you override pretty much anything in speechd.conf. Since that is true, isn't the real problem how to give Sugar Activities a way to get these values set up for them using some data store maintained by your control panel? The data store doesn't have to be speechd.conf. It could be any file that can be updated by your control panel and read by other Activities. The Sugar API could have a method that takes the speechd client as a parameter and applies all the system-wide defaults that you are maintaining to it. After that the Activity could make changes on its own and save the values as meta information or whatever. So basically in my proposal speech-dispatcher starts up the normal way with whatever default values are set. Your control panel maintains its own values in a datastore that the Sugar API can read. Activities use the Sugar API to set speech to these values, or they would use meta information to store their own values and use those values to initialize the SD client. An Activity *could* just use whatever defaults were in speechd.conf, but that would be considered bad form. In any case, speechd does not have to run with dangerous permissions and Sugar Activities should get the benefit of your control panel with minimal work. James Simmons ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues
On Thu, Jul 17, 2008 at 05:21:57PM +0530, Hemant Goyal wrote: The corresponding strace outputs are : open(/var/log//speechd.log, O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 EACCES (Permission denied) open(/var/log//espeak.log, O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EACCES (Permission denied) Your software is attempting to create-or-truncate its pid-file and log-files and is failing. If you make these files world-writable (or at least speechd writable) by, e.g., touch /var/run/speech-dispatcher.pid chmod a+w /var/run/speech-dispatcher.pid ... (repeat for speechd.log and espeak.log) What happens when you redo your tests? Michael P.S. - In the long run, speechd should probably learn to run under its own uid(s). Then the appropriate uids can own the appropriate log files. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
