On Mon, 2005-05-09 at 14:04 +0100, Mike Hearn wrote:
Hi Ivan,
I saw your work on the restricted $HOME SELinux policy and this interests me a great deal (both with my Codeweavers hat and my autopackage hat on).
I'd like to discuss this in a more public forum. Is the Fedora SELinux list a good place to talk about this sort of lockdown?
Ok. Basically my plan is to see how SELinux can be used to confine all applications, including various "desktop" programs - content handlers and such. I dislike how so many things that are completely unrelated are marked ROLE_home_t under /home, and a lot of things are marked ROLE_tmp_t under /tmp. I think there should be better labeling of /home, and /tmp.
As part of this, I have suggested various changes, including:
- per domain labeling of ORBit sockets in /tmp, so apps don't have to access ROLE_tmp_t
- confining various GNOME daemons to make use of this - starting with GConf, and gnome-vfs-daemon
- labeling of the various GNOME hidden folders in /home with a more specific context than ROLE_home_t
- restricting mozilla and other programs that interact with the web to writing ROLE_untrusted_content_t, as opposed to ROLE_home_t (or something stranger, like ROLE_mozilla_home_t, which is the current behavior)
- labeling per/user fonts, and .desktop files, and writing macros to make those work
- in the future, content-specific types such as ROLE_media_content_t, that content handlers can access.
I have a bug tracking this here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155800
although right now this is just one large patch, not nearly where it should be, and unsuitable for merging. I have sent Daniel Walsh several smaller patches to begin implementing this - I need to update the bug to reflect that, since the large patch is a bit out of date.
===========================
The untrusted_content part of this is a proposal for a type to be used to mark things downloaded from the Internet that cannot be trusted (hence..untrusted). The idea is that various web browsers, p2p clients, etc. will use this type to store content.
Then the user would have to perform some sort of action to interact with this type, to make it accessible by other programs. This would be simply to relabel the file to a different type to begin with, but in the future an automated mechanism could be used to do this, or selinux integration with nautilus could be used to relabel the files. There were also suggestions of a virus scan before such content type would be made accessible.
Basically, for starters I just want better labeling of content downloaded by mozilla, because ROLE_mozilla_home_t is just wrong - it's the same type as is used for internal mozilla settings (.mozilla). Then after the type exists, we can figure out what to do with it.
To make this work I wanted there to be a folder in /home called downloads or something like that created by default. Then things stored there would automatically get the right type. I suggested that the GNOME team create such a folder, and integrate it with the Places menu, but I don't think there was a lot of interest on the Usability list - in any case people disagree about what it should be called, or whether it's important to have such a folder. I haven't decided what to do about this - currently my patch simply labels downloads and ".*Downloads" as ROLE_untrusted_content_t, if they are present. It also changes the type of files saved by mozilla in tmp to ROLE_untrusted_content_t.
On Mon, 09 May 2005 16:57:06 -0400, Ivan Gyurdiev wrote:
The untrusted_content part of this is a proposal for a type to be used to mark things downloaded from the Internet that cannot be trusted (hence..untrusted). The idea is that various web browsers, p2p clients, etc. will use this type to store content.
OK. What problem are we trying to solve here, exactly: that users want to run programs they download in some kind of quarantine zone? Or is the idea that actual data files may be problematic and need to be kept from other programs? I can't see any system that requires freeing data files being successful, people download way too many, but programs maybe ...
It seems that the most common type of program to download and run is an installer or package. Right now they [usually] need root to work, but figuring out exactly what privs an installer or package really needs would probably be a good idea.
Can you give some use cases where this sort of untrusted content type prevents Bob from damaging or accidentally subverting his system?
thanks -mike
Or is the idea that actual data files may be problematic and need to be kept from other programs?
Yes... malformed content to make a program crash.
I can't see any system that requires freeing data files being successful, people download way too many, but programs maybe ...
Why is that? Currently working with SELinux is kind of a pain, because there's command line tools, and that's it. I know Daniel Walsh has a nautilus integration patch. I've been planning to work on improving that, and allow its use for relabeling content to various "customizable" types, but I haven't gotten to it yet.
Also, there have been proposals for more automated approaches to this. I thought maybe various content handlers could register the security label they can handle, and when the user attempts to open a file of that type, it can be relabeled automatically (after warning the user, or scanning the file). Some of this was discussed on NSA-list, and on GNOME-Usability-list.
In any case, I have a very concrete, and small proposal here, not something in the distant future:
1) Replace the mozilla downloaded content type from ROLE_mozilla_home_t, which seems completely wrong, to ROLE_untrusted_content_t
2) Replace the giFT downloaded content type from ROLE_gift_home_t, which seems completely wrong, to ROLE_untrusted_content_t
3) Replace the /tmp mozilla type from ROLE_mozilla_tmp_t to ROLE_untrusted_content_t
This has the following immediate benefits:
- Downloaded content can be distinguished from internal program settings, and such...
- There is a common type, instead of multiple types depending on the program.
Then we have to figure out what to do with this type. In the immediate future we could:
- permit full access to it from ROLE_t
- deny access to it, and require that people relabel this stuff
- a combination of both, toggled by a boolean
- something different, smarter, subject to discussion
It's important to realize that the lack of common type is a problem. Also, ROLE_home_t is an unsuitable common type - because everything's labeled ROLE_home_t, including all kinds of important files that we don't want random programs to access and overwrite.
Can you give some use cases where this sort of untrusted content type prevents Bob from damaging or accidentally subverting his system?
1) A common type is needed for downloads.
2) That common type can't be ROLE_home_t, for security purposes. It shouldn't be ROLE_mozilla_home_t, or something like that either, that's used for other stuff - it should be a new type, dedicated to downloads.
3) Once a common type is created, it can be used for various fun things, such as virus protection. Programs can be prevented from accessing content of this type in certain ways by the sysadmin....for example to prevent people from executing hostile content from the net.
On Tue, 10 May 2005 19:12:01 -0400, Ivan Gyurdiev wrote:
In any case, I have a very concrete, and small proposal here, not something in the distant future:
OK, it all seems sensible.
A common type is needed for downloads.
That common type can't be ROLE_home_t, for security purposes.
It shouldn't be ROLE_mozilla_home_t, or something like that either, that's used for other stuff - it should be a new type, dedicated to downloads.
- Once a common type is created, it can be used for various fun things,
such as virus protection. Programs can be prevented from accessing content of this type in certain ways by the sysadmin....for example to prevent people from executing hostile content from the net.
Would it be OK to figure out a certain set of permissions that is OK for random untrusted software to use. For instance Flash developers get a lot of milage out of the ability to write fun games that operate entirely inside the Flash sandbox which is pretty restrictive, it seems like there should be some level of control we can give programs so that humanities innate urge to distribute electronic greetings cards can be satisifed securely :)
The thing I'm not really sure about is why preventing programs from accessing downloaded data files is useful. If you know you can overflow a program with malicious data the only sure protection is to fix the app, right? It seems a bit different to viruses which are actually programs.
thanks -mike
Would it be OK to figure out a certain set of permissions that is OK for random untrusted software to use. For instance Flash developers get a lot of milage out of the ability to write fun games that operate entirely inside the Flash sandbox which is pretty restrictive, it seems like there should be some level of control we can give programs so that humanities innate urge to distribute electronic greetings cards can be satisifed securely :)
Mozilla is allowed to execute downloaded content right now... I think for Java it transitions to a special javaplugin domain. I suppose the same thing can be setup for flash, if necessary.
The thing I'm not really sure about is why preventing programs from accessing downloaded data files is useful. If you know you can overflow a program with malicious data the only sure protection is to fix the app, right? It seems a bit different to viruses which are actually programs.
Fixing the app is one aspect of security, and probably the most important one. However, it might not always be possible - what about third-party closed software? Besides, maybe you just don't trust the app, and you don't want to allow it to handle potentially hostile content. SELinux is mostly about containment, and allowing the sysadmin to control interactions between various domains and objects. If we can give the sysadmin a say in how potentially hostile content is handled, I think we should.
Basically, the content you download from the Internet has to be labeled somehow, and the current labeling scheme is not appropriate IMHO. I want to setup a better labeling scheme. I don't know at this point exactly how it might be taken advantage of, but I'm sure there's all kinds of things that can be done to improve security, with a common hostile content type, as opposed to multiple hostile content types, or worse, no differentiation from ROLE_home_t.
=================
By the way, since you're involved with Codeweavers - does all of wine require text relocations? If so, it needs to be marked textrel_shlib_t. I should probably file a policy bug, because it doesn't work at all under SELinux strict - I use wine quite a lot (games on Linux!), and it's annoying that I have to turn SELinux off all the time to make use of it.
for FILE in /usr/local/lib/wine/*.so; do if [ ! -z "`readelf -d $FILE| grep TEXTREL`" ]; then echo $FILE; fi; done;
(result: everything)
wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: cannot restore segment prot after reloc: Permission denied
On Tue, 10 May 2005 21:34:36 -0400, Ivan Gyurdiev wrote:
By the way, since you're involved with Codeweavers - does all of wine require text relocations? If so, it needs to be marked textrel_shlib_t.
I'm not sure, I haven't examined the reasons we have text relocs in depth. Wines build system is complex, and I've not seen any documentation on what kind of things can trigger this. A hunch is maybe it's related to the embedded NT headers.
I should probably file a policy bug, because it doesn't work at all under SELinux strict - I use wine quite a lot (games on Linux!), and it's annoying that I have to turn SELinux off all the time to make use of it.
I was wondering about that :) I couldn't quite figure out whether the textrel thing was both targetted and strict or just strict: seems like it's just strict <phew> :)
Marking libs as textrel_shlib_t should be done automatically by the patched install IMHO. We don't have any bugs filed on this in WineHQ/Codeweavers bugzilla so right now I guess not many people are trying to use strict on a desktop. But obviously if we can fix this easily then that'd be great.
Actually I was talking to Jeremy (White) about this the other day. We'd be happy to kick in a free copy of Crossover for SELinux developers if they were interested in testing things with it. I saw that Steven Smalley is testing new restrictions like execstack with programs like Java, Mozilla, OpenOffice etc: getting Wine/Crossover (they're virtually the same) into that list would be great.
It's a little tricky because I guess most SELinux developers are running strict, but most of our customers/users are running targetted (or not running SELinux at all), so there's not much commercial pressure to fix problems that only affect strict. Whereas for instance in execshield we had to put a lot of work into supporting it :( Still it'd be nice to know in advance about these things, especially if bits of strict are going to migrate to targetted at some point.
thanks -mike
Mike Hearn wrote:
On Tue, 10 May 2005 21:34:36 -0400, Ivan Gyurdiev wrote:
By the way, since you're involved with Codeweavers - does all of wine require text relocations? If so, it needs to be marked textrel_shlib_t.
I'm not sure, I haven't examined the reasons we have text relocs in depth. Wines build system is complex, and I've not seen any documentation on what kind of things can trigger this. A hunch is maybe it's related to the embedded NT headers.
I should probably file a policy bug, because it doesn't work at all under SELinux strict - I use wine quite a lot (games on Linux!), and it's annoying that I have to turn SELinux off all the time to make use of it.
I was wondering about that :) I couldn't quite figure out whether the textrel thing was both targetted and strict or just strict: seems like it's just strict <phew> :)
Marking libs as textrel_shlib_t should be done automatically by the patched install IMHO. We don't have any bugs filed on this in WineHQ/Codeweavers bugzilla so right now I guess not many people are trying to use strict on a desktop. But obviously if we can fix this easily then that'd be great.
Currently textrel_shlib_t == shlib_t == lib_t in targeted policy. That can and should probably change in the future as we tighten up security of the userspace with SELinux.
Actually I was talking to Jeremy (White) about this the other day. We'd be happy to kick in a free copy of Crossover for SELinux developers if they were interested in testing things with it. I saw that Steven Smalley is testing new restrictions like execstack with programs like Java, Mozilla, OpenOffice etc: getting Wine/Crossover (they're virtually the same) into that list would be great.
I would take a look at it. Mainly need a list of shared libraries and whether then need textrel support. But other issues will probably arise.
It's a little tricky because I guess most SELinux developers are running strict, but most of our customers/users are running targetted (or not running SELinux at all), so there's not much commercial pressure to fix problems that only affect strict. Whereas for instance in execshield we had to put a lot of work into supporting it :( Still it'd be nice to know in advance about these things, especially if bits of strict are going to migrate to targetted at some point.
They will, and they are.
thanks -mike
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Marking libs as textrel_shlib_t should be done automatically by the patched install IMHO. We don't have any bugs filed on this in WineHQ/Codeweavers bugzilla so right now I guess not many people are trying to use strict on a desktop. But obviously if we can fix this easily then that'd be great.
If libs are marked textrel_shlib_t in the policy, they will be automatically relabeled as such by the rpm installer, as well as the install command on Fedora.
However, they are not marked as such - Daniel, perhaps /usr(/local)?/lib/wine/.*.so -- textrel_shlib_t should be added?
On the other hand, if wine doesn't need text relocations, it would be better if it was compiled without them.
On Wed, 2005-05-11 at 12:56 -0400, Ivan Gyurdiev wrote:
However, they are not marked as such - Daniel, perhaps /usr(/local)?/lib/wine/.*.so -- textrel_shlib_t should be added?
That is a bit hacky. I personally install Wine to /opt/wine and Crossover can go anywhere. I think it'd be better to adjust the Wine build system to label them correctly.
On the other hand, if wine doesn't need text relocations, it would be better if it was compiled without them.
I have no idea why they're there, like I said, there's no documentation I could find on what causes the toolchain to produce them. How do you go about getting rid of them? They're compiled with -fPIC already.
thanks -mike
On Wed, 2005-05-11 at 18:25 +0100, Mike Hearn wrote:
On Wed, 2005-05-11 at 12:56 -0400, Ivan Gyurdiev wrote:
However, they are not marked as such - Daniel, perhaps /usr(/local)?/lib/wine/.*.so -- textrel_shlib_t should be added?
That is a bit hacky. I personally install Wine to /opt/wine and Crossover can go anywhere. I think it'd be better to adjust the Wine build system to label them correctly.
That's not how SELinux works right now - labeling decisions are centralized in the policy. I'm not sure why it's done that way - perhaps it's because the policy sources are also centralized.
(cc-ed Stephen Smalley - maybe he can explain)
If you label wine in the build system, and later I run restorecon, which brings the system permissions in sync with what the file_contexts file says, it will restore the permissions back to what the policy thinks they should be.
On the other hand, if wine doesn't need text relocations, it would be better if it was compiled without them.
I have no idea why they're there, like I said, there's no documentation I could find on what causes the toolchain to produce them. How do you go about getting rid of them? They're compiled with -fPIC already.
Not sure about that - my guesses run out with fPIC...
(sorry for resend - incorrect recipient)
On Wed, 2005-05-11 at 18:25 +0100, Mike Hearn wrote:
On Wed, 2005-05-11 at 12:56 -0400, Ivan Gyurdiev wrote:
However, they are not marked as such - Daniel, perhaps /usr(/local)?/lib/wine/.*.so -- textrel_shlib_t should be added?
That is a bit hacky. I personally install Wine to /opt/wine and Crossover can go anywhere. I think it'd be better to adjust the Wine build system to label them correctly.
That's not how SELinux works right now - labeling decisions are centralized in the policy. I'm not sure why it's done that way - perhaps it's because the policy sources are also centralized.
(cc-ed Stephen Smalley - maybe he can explain)
If you label wine in the build system, and later I run restorecon, which brings the system permissions in sync with what the file_contexts file says, it will restore the permissions back to what the policy thinks they should be.
On the other hand, if wine doesn't need text relocations, it would be better if it was compiled without them.
I have no idea why they're there, like I said, there's no documentation I could find on what causes the toolchain to produce them. How do you go about getting rid of them? They're compiled with -fPIC already.
Not sure about that - my guesses run out with fPIC...
On Wed, 11 May 2005 12:56:33 -0400, Ivan Gyurdiev wrote:
On the other hand, if wine doesn't need text relocations, it would be better if it was compiled without them.
I investigated this, they're basically unavoidable without lots of pain.
They're being generated by the assembly we use for IAT thunks. We need them because Wine does its own linking even for ELF DLLs.
thanks -mike
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Ivan Gyurdiev -
Mike Hearn