Untrusted content domain

Ivan Gyurdiev ivg2 at cornell.edu
Tue May 10 23:12:01 UTC 2005


> 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 at cornell.edu>
Cornell University




More information about the fedora-selinux-list mailing list