Bug 129584 - Firefox and read/write permissions
Firefox and read/write permissions
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
rawhide
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-10 12:49 EDT by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-15 13:19:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2004-08-10 12:49:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040706 Firefox/0.9.1

Description of problem:
mozilla_readhome and mozilla_writehome in mozilla.te are 
false by default. Why?

Also, why readhome and writehome? I should be able to browse
everything that the user has access to (therefore use mozilla
to browse the local filesystem / open local web pages), and write
everywhere that the user can write to (save as...) 
 
Doesn't work that way:

allow user_mozilla_t proc_t:dir { getattr };
        #EXE=/usr/lib/firefox-0.9.1/firefox-bin  PATH=/proc   :  getattr
 
allow user_mozilla_t sbin_t:dir { getattr };
        #EXE=/usr/lib/firefox-0.9.1/firefox-bin  PATH=/sbin   :  getattr
 
allow user_mozilla_t security_t:dir { getattr };
        #EXE=/usr/lib/firefox-0.9.1/firefox-bin  PATH=/selinux   : 
getattr
 
allow user_mozilla_t staff_home_dir_t:dir { getattr };
        #EXE=/usr/lib/firefox-0.9.1/firefox-bin  PATH=/root   :  getattr
 
allow user_mozilla_t sysfs_t:dir { getattr };
        #EXE=/usr/lib/firefox-0.9.1/firefox-bin  PATH=/sys   :  getattr

allow user_mozilla_t httpd_sys_content_t:file { getattr read };
        #EXE=/usr/lib/firefox-0.9.1/firefox-bin 
PATH=/var/www/html/bg.gif   :  getattr
        #EXE=/usr/lib/firefox-0.9.1/firefox-bin  NAME=bg.gif   :  read



Version-Release number of selected component (if applicable):
selinux-policy-strict-1.15.13-1

How reproducible:
Always

Steps to Reproduce:
1. See Summary
    

Additional info:
Comment 1 Ivan Gyurdiev 2004-08-10 13:44:38 EDT
Look at what happens when I open /etc with nautilus.

[root@cobra phantom]# dmesg|audit2allow -l -v|grep naut
        #EXE=/usr/bin/nautilus  NAME=adjtime   :  read
        #EXE=/usr/bin/nautilus  NAME=bluetooth   :  read
        #EXE=/usr/bin/nautilus  NAME=bluetooth   :  search
        #EXE=/usr/bin/nautilus  PATH=/etc/firmware/microcode.dat   : 
getattr
        #EXE=/usr/bin/nautilus  NAME=aliases.db   :  read
        #EXE=/usr/bin/nautilus  NAME=dbus-1   :  read
        #EXE=/usr/bin/nautilus  NAME=dbus-1   :  search
        #EXE=/usr/bin/nautilus  PATH=/etc/dbus-1/system.conf   :  getattr
        #EXE=/usr/bin/nautilus  NAME=mail   :  read
        #EXE=/usr/bin/nautilus  NAME=mail   :  search
        #EXE=/usr/bin/nautilus  PATH=/etc/mail/Makefile   :  getattr
        #EXE=/usr/bin/nautilus  NAME=prelink.conf   :  read
        #EXE=/usr/bin/nautilus  NAME=prelink.conf   :  read
        #EXE=/usr/bin/nautilus  PATH=/etc/prelink.conf   :  getattr
        #EXE=/usr/bin/nautilus  NAME=exports   :  read
        #EXE=/usr/bin/nautilus  NAME=exports   :  read
        #EXE=/usr/bin/nautilus  PATH=/etc/exports   :  getattr
        #EXE=/usr/bin/nautilus  NAME=httpd   :  read
        #EXE=/usr/bin/nautilus  NAME=httpd   :  search
        #EXE=/usr/bin/nautilus  PATH=/etc/httpd/logs   :  getattr
        #EXE=/usr/bin/nautilus  NAME=logs   :  read
        #EXE=/usr/bin/nautilus  PATH=/etc/httpd/modules   :  getattr
        #EXE=/usr/bin/nautilus  NAME=modules   :  read
        #EXE=/usr/bin/nautilus  PATH=/etc/lvm/archive   :  getattr
        #EXE=/usr/bin/nautilus  PATH=/etc/lvm/.cache   :  getattr
        #EXE=/usr/bin/nautilus  PATH=/etc/samba/secrets.tdb   :  getattr
        #EXE=/usr/bin/nautilus  NAME=.aumixrc   :  read
        #EXE=/usr/bin/nautilus  PATH=/etc/ssh/ssh_host_key   :  getattr
        #EXE=/usr/bin/nautilus  NAME=cron.d   :  read
        #EXE=/usr/bin/nautilus  PATH=/etc/cron.d   :  getattr
        #EXE=/usr/bin/nautilus  NAME=cron.d   :  search
        #EXE=/usr/bin/nautilus  PATH=/etc/cron.d/sysstat   :  getattr
        #EXE=/usr/bin/nautilus 
PATH=/tftpboot/linux-install/pxelinux.0   :  getattr
        #EXE=/usr/bin/nautilus  NAME=pxelinux.0   :  read
        #EXE=/usr/bin/nautilus  NAME=dev.d   :  read
        #EXE=/usr/bin/nautilus  NAME=dev.d   :  search
        #EXE=/usr/bin/nautilus  PATH=/etc/security/console.apps   : 
getattr
Comment 2 Ivan Gyurdiev 2004-08-10 21:20:27 EDT
Why audit read/write/execute/getattr for user_t at all?
Isn't this handled by standard Unix permissions? 
I understand selinux must restrict, but I'm logged into
my shell here, and I want things to work as expected.
Seems like read/getattr permission for file browsers should also
be determined by rwx permissions. 

Look, I can't even read some things in /etc, even though they have the
read flag on.

allow user_t etc_mail_t:file { getattr };
        #EXE=/bin/ls  PATH=/etc/mail/Makefile   :  getattr
 
allow user_t exports_t:file { getattr read };
        #EXE=/bin/ls  PATH=/etc/exports   :  getattr
        #EXE=/bin/cat  NAME=exports   :  read
 
Maybe I'm misunderstanding what SElinux is supposed to do for me.
If so, please explain. My view of it was that it's supposed to 
restrict various programs to the least amount of priviledge, but still
remain completely transparent and allow everything to work as before.
In order for that to happen, things like ls and cat should be able
to work on any file with the proper rwx flags... or am I totally on
the wrong track?
Comment 3 Daniel Walsh 2004-08-11 17:04:17 EDT
Decisions have been made within SELinux on what applications should be
designed to do.  A web browser is designed to read web pages via HTML.
 While it is true the application has evolved to be able to browse
files within the environment, that is really not it's intended job. 
If the browser becomes compromized, it would be able to read files off
the local system and possible send them to a remote site.  So policy
was written to prevent the browser applications from reading standard
files.  
You can mark files as mozilla readable via chcon command.  The
mozilla_readhome and mozilla_writehome tunables/booleans turn off this
protection.  We are in the midst of transitioning the code from
tunables to booleans, so you maybe seeing a result of that.  
You can uses the setsebool mozilla_writehome 1
command to turn on the boolean.

We should have the new boolean infrastructure in place this week.
Comment 4 Ivan Gyurdiev 2004-08-11 20:31:14 EDT
<i> 
Decisions have been made within SELinux on what applications should be
designed to do.  A web browser is designed to read web pages via HTML.
While it is true the application has evolved to be able to browse
files within the environment, that is really not it's intended job. 
If the browser becomes compromized, it would be able to read files off
the local system and possible send them to a remote site.
</i>

Yes, but this is affecting functionality. The application was able to
do this before selinux was installed, and is not able to do this
anymore. Now I am left with an inferior system due to installing
SElinux, which I do not like. I don't see much point to browsing the
filesystem with mozilla either, but I frequently use it to view local
HTML content. Also, what will you do about the rest of the file
browsers (nautilus, konqueror...), which will have to be able to
freely browse the filesystem based on read permission.

<i>
You can mark files as mozilla readable via chcon command. 
</i>

I don't think the user of a file browser will be marking files via
chcon prior to browsing them. Usually he/she expects them to be
browsable if the read bit is set. See my previous comment on auditing
read/write/exec for user_t...

<i> You can uses the setsebool mozilla_writehome 1
command to turn on the boolean. </i>

readhome and writehome are just a special case of the more general
question - how will a file browser (whether mozilla or another one) be
able to browse all readable files (and descend into all executable dirs)
Comment 5 Daniel Walsh 2004-09-15 13:19:38 EDT
Yes, but this is affecting functionality. The application was able to
do this before selinux was installed, and is not able to do this
anymore. Now I am left with an inferior system due to installing
SElinux, which I do not like. I don't see much point to browsing the
filesystem with mozilla either, but I frequently use it to view local
HTML content. Also, what will you do about the rest of the file
browsers (nautilus, konqueror...), which will have to be able to
freely browse the filesystem based on read permission.

<dan> 
Sorry about not getting back to this till now.  We should have this
conversation on a public list Fedora or the SELinux list.

nautilus is not currently run under it's own context so it can read
all files allowed to be read by the user.  Konqueror is run under the
mozilla context.  

If you want to run the applications as they were always run then you
should be running targeted policy.  Strict policy is for a more locked
down machine.  
</dan>

I don't think the user of a file browser will be marking files via
chcon prior to browsing them. Usually he/she expects them to be
browsable if the read bit is set. See my previous comment on auditing
read/write/exec for user_t...
<dan>
Allowing applications to read/write/exec random applications will
eliminate the security provided by SELinux to user space.  
</dan>
<i> You can uses the setsebool mozilla_writehome 1
command to turn on the boolean. </i>

readhome and writehome are just a special case of the more general
question - how will a file browser (whether mozilla or another one) be
able to browse all readable files (and descend into all executable dirs)

<dan>  

A general file browser will be allowed to run as user_t (Naughtilus).  
Programs with defined policy will be locked down to a tighter degree.

</dan>
Comment 6 Ivan Gyurdiev 2004-09-15 13:49:57 EDT
"A general file browser will be allowed to run as user_t (Naughtilus).  
Programs with defined policy will be locked down to a tighter degree."

I think the problem is that user_t is being denied access to 
various files in /etc (and other places) which have the correct read,
write, and execute flags but are restricted by context rules. Last
time I tried to browse things in /etc from the shell or from nautilus
I got a storm of denials even though I would have been able to perform
the operation if selinux had not been installed. 

"Allowing applications to read/write/exec random applications will
eliminate the security provided by SELinux to user space."

I was referring specifically to user_t applications.
Should cat not be able to read any file that has the read bit set?

From above:

allow user_t exports_t:file { getattr read };
        #EXE=/bin/ls  PATH=/etc/exports   :  getattr
        #EXE=/bin/cat  NAME=exports   :  read








 
Comment 7 Daniel Walsh 2004-09-15 14:03:25 EDT
Not necessarily.  In the case of exports, yes it should.  In some
cases the Descretionary Access Control of an file is lower then
necessary in order that all applications that run as that user have
access to it.  In the case of Mandatory Access Control, certain
applications have no need to look at file should not be granted
access.  So there is no reason why Mozilla should be allowed to read
the /etc/exports file so it is denied by MAC even though it is allowed
by DAC.  The idea of Mandatory Access Control is to define a system
with application have the least acceess required to get their job done.

I will change the policy to allow reads of /etc/exports by the user_t.

Dan
Comment 8 Ivan Gyurdiev 2004-09-15 15:48:40 EDT
"The idea of Mandatory Access Control is to define a system
with application have the least acceess required to get their job done."

Some applications just seem to need a lot of freedom to get their job
done. I certainly expect to be able to `cat` every file which is
flagged readable on a Linux system. Otherwise why would it be readable
in the first place? I'll have to reinstall SELinux and retest, because
I'm positive I can find a large number of files which user_t cannot
access though it should be able to. I'll retest the entire nautilus
list posted as comment 2. 

No time now though - school's tough.


Comment 9 Daniel Walsh 2004-09-15 15:55:51 EDT
Yes there are a lot of files that user can not access.  Mainly any
file that has a security context associated with it and doesn't have
the attribute usercanread.  

Again I want to bring this conversation to the public list and come to
concensus.  We can add usercanread to these files, but the question
than is should a user be able to read all files even if they are world
readable.

Note You need to log in before you can comment on or make changes to this bug.