3:57 p.m.
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.
2:30 p.m.
New subject: Untrusted content domain
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
6:12 p.m.
New subject: Untrusted content domain
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.
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
6:52 p.m.
New subject: Untrusted content domain
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.
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.
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
8:34 p.m.
New subject: Untrusted content domain
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
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
7:47 a.m.
New subject: Untrusted content domain
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
9:21 a.m.
New subject: Untrusted content domain
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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
11:56 a.m.
New subject: Untrusted content domain
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.
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
12:25 p.m.
New subject: Untrusted content domain
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
12:47 p.m.
New subject: Untrusted content domain
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...
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
12:49 p.m.
New subject: Untrusted content domain
(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...
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
12:44 p.m.
New subject: Untrusted content domain
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
6936
days inactive
6938
days old
selinux@lists.fedoraproject.org
11 comments
3 participants
participants (3)
-
Daniel J Walsh -
Ivan Gyurdiev -
Mike Hearn