Confining User Space
My SELinux goal in Fedora 9 is to begin confining user space. Confinement of user space has to be optional, to make sure SELinux does not get a Black Eye for breaking some random application.
Confining the Web Browser:
People interested in SELinux usually have a goal of making the desktop more secure. "How do we prevent the types of attacks that Microsoft suffers from?" These types of questions usually come down to securing the Web Browser, since the web browser reads untrusted data all the time, and tends to run random software.
Policy writers have tried to use SELinux to secure the web browser over the years, with little success. A modern desktop has too many communications paths, trying to prevent a determined hacker taking advantage of a Web Browser vulnerability is difficult.
Some problems with confining the Browser:
- If I prevent the browser from uploading files or downloading files, the user has a hard time understanding why?
- The browser launches helper apps OpenOffice, Evince, Acroread to look at documents. If these apps are not able to read/write directories, because of Browser policy, users will get confused and upset. As an example, if I said Firefox can not write to your home directory, except the .mozilla directory. Then I open a OpenOffice document in Firefox, OpenOffice would not be allowed to write to the homedir. But if the user uses the running OpenOffice to edit a different file, it will not work, he will not be able to save this document either.
- Finally there is the issue of people downloading software to be run inside of the browser. Users have been trained over the last few years to download and run apps off of web servers. What 14 year old boy, when prompted if he wants to see Dancing Bikinis, will not answer YES. Sadly my 14 year old boys, have moved onto worse then Bikinis.
At the First SELinux Summit a few years ago Colin Walters, did a talk about confining the Firefox Plugins rather then the App. He said, if we could confining the millions of lines of code, that people download off the WEB, we might be able to protect the web browser without ruining the user experience. He was talking about things like FlashPlayer, mplayer, sound codec, video codec, other assorted media plugins. But alas the libraries we integrated directly into a single process, until now.
Gwenole Beauchesne developed the nsplugin wrapper.
http://gwenole.beauchesne.info/projects/nspluginwrapper/
"nspluginwrapper is an Open Source compatibility plugin for Netscape 4 (NPAPI) plugins. That is, it enables you to use plugins on platforms they were not built for. For example, you can use the Adobe Flash plugin on Linux/x86_64, NetBSD and FreeBSD platforms."
Fedora has been shipping this for a couple of releases, and I have added policy for it.
When you run Firefox and go to a site that requires a plugin, the npviewer.bin application application starts and communicates back to firefox.
I have added confinement this process.
# ps -eZ | grep nsplugin
staff_u:staff_r:nsplugin_t:s0 30628 ? 00:00:01 npviewer.bin
While Firefox continues to run as unconfined_t.
I have also added a boolean, allow_unconfined_nsplugin_transition (Default off), that allows you to specify whether you want this confinement when running as the unconfined user. I have been running with confined plugins for the past couple of weeks. You might need to fix the labeling on your homedir to make this work. restorecon -R -v ~/ Should fix it.
The policy for nsplugin allows it to only connect to HTTP ports, macromedia port and ldap ports. It can only write to the .mozilla, .adobe, .macromedia homedir directories. It can read some files in /etc and /usr, but not files like /etc/shadow.
You can try this out by updating to the latest Fedora 9 code, and
# setsebool -P allow_unconfined_nsplugin_transition 1
I would like to know of any problems this causes.
Type your cut contents here.
Confining the Web Browser:
People interested in SELinux usually have a goal of making the desktop more secure. "How do we prevent the types of attacks that Microsoft suffers from?" These types of questions usually come down to securing the Web Browser, since the web browser reads untrusted data all the time, and tends to run random software.
Policy writers have tried to use SELinux to secure the web browser over the years, with little success. A modern desktop has too many communications paths, trying to prevent a determined hacker taking advantage of a Web Browser vulnerability is difficult.
Some problems with confining the Browser:
- If I prevent the browser from uploading files or downloading files, the user has a hard time understanding why?
- The browser launches helper apps OpenOffice, Evince, Acroread to look at documents. If these apps are not able to read/write directories, because of Browser policy, users will get confused and upset. As an example, if I said Firefox can not write to your home directory, except the .mozilla directory. Then I open a OpenOffice document in Firefox, OpenOffice would not be allowed to write to the homedir. But if the user uses the running OpenOffice to edit a different file, it will not work, he will not be able to save this document either.
- Finally there is the issue of people downloading software to be run inside of the browser. Users have been trained over the last few years to download and run apps off of web servers. What 14 year old boy, when prompted if he wants to see Dancing Bikinis, will not answer YES. Sadly my 14 year old boys, have moved onto worse then Bikinis.
At the First SELinux Summit a few years ago Colin Walters, did a talk about confining the Firefox Plugins rather then the App. He said, if we could confining the millions of lines of code, that people download off the WEB, we might be able to protect the web browser without ruining the user experience. He was talking about things like FlashPlayer, mplayer, sound codec, video codec, other assorted media plugins. But alas the libraries we integrated directly into a single process, until now.
Gwenole Beauchesne developed the nsplugin wrapper.
http://gwenole.beauchesne.info/projects/nspluginwrapper/
"nspluginwrapper is an Open Source compatibility plugin for Netscape 4 (NPAPI) plugins. That is, it enables you to use plugins on platforms they were not built for. For example, you can use the Adobe Flash plugin on Linux/x86_64, NetBSD and FreeBSD platforms."
Fedora has been shipping this for a couple of releases, and I have added policy for it.
When you run Firefox and go to a site that requires a plugin, the npviewer.bin application application starts and communicates back to firefox.
I have added confinement this process.
# ps -eZ | grep nsplugin
staff_u:staff_r:nsplugin_t:s0 30628 ? 00:00:01 npviewer.bin
While Firefox continues to run as unconfined_t.
I have also added a boolean, allow_unconfined_nsplugin_transition (Default off), that allows you to specify whether you want this confinement when running as the unconfined user. I have been running with confined plugins for the past couple of weeks. You might need to fix the labeling on your homedir to make this work. restorecon -R -v ~/ Should fix it.
The policy for nsplugin allows it to only connect to HTTP ports, macromedia port and ldap ports. It can only write to the .mozilla, .adobe, .macromedia homedir directories. It can read some files in /etc and /usr, but not files like /etc/shadow.
You can try this out by updating to the latest Fedora 9 code, and
# setsebool -P allow_unconfined_nsplugin_transition 1
I would like to know of any problems this causes.
Type your cut contents here.