selinux support ?

[pgera]

Tried running this on RHEL 7, and it gets denied by selinux. Here's the log:

SELinux is preventing /usr/lib64/firefox/plugin-container from execute access on the file /home/username/.mozilla/plugins/libfreshwrapper-flashplayer.so.

*****  Plugin mozplugger (99.1 confidence) suggests   ************************

If you want to use the plugin package
Then you must turn off SELinux controls on the Firefox plugins.
Do
# setsebool -P unconfined_mozilla_plugin_transition 0

*****  Plugin catchall (1.81 confidence) suggests   **************************

If you believe that plugin-container should be allowed execute access on the libfreshwrapper-flashplayer.so file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep plugin-containe /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c
                              0.c1023
Target Context                system_u:object_r:nfs_t:s0
Target Objects                /home/username/.mozilla/plugins/libfreshwrapper-
                              flashplayer.so [ file ]
Source                        plugin-containe
Source Path                   /usr/lib64/firefox/plugin-container
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           firefox-38.6.1-1.el7_2.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-60.el7_2.3.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     hostname
Platform                      Linux hostname
                              3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23
                              04:54:55 EST 2016 x86_64 x86_64
Alert Count                   8
First Seen                    2016-03-01 01:11:06 EST
Last Seen                     2016-03-01 01:11:12 EST
Local ID                      5f448028-d1bb-4938-a468-5ef7d48c7f7b

Raw Audit Messages
type=AVC msg=audit(1456812672.172:51075): avc:  denied  { execute } for  pid=16939 comm="plugin-containe" path="/home/username/.mozilla/plugins/libfreshwrapper-flashplayer.so" dev="0:50" ino=17254594584 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nfs_t:s0 tclass=file

type=SYSCALL msg=audit(1456812672.172:51075): arch=x86_64 syscall=mmap success=no exit=EACCES a0=0 a1=301540 a2=5 a3=802 items=0 ppid=16774 pid=16939 auid=6074 uid=6074 gid=7001 euid=6074 suid=6074 fsuid=6074 egid=7001 sgid=7001 fsgid=7001 tty=(none) ses=1168 comm=plugin-containe exe=/usr/lib64/firefox/plugin-container subj=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 key=(null)

Hash: plugin-containe,mozilla_plugin_t,nfs_t,file,execute

Before I do setsebool -P unconfined_mozilla_plugin_transition 0, I would like to know why it's being denied, and whether it's safe to set that bool to 0.

[i-rinat]

selinux support?

What kind of support? As far as I know, there are "forbidden by default" policies in SELinux, and one must explicitly allow various capabilities.

why it's being denied

From "syscall=mmap" I can guess, mmap syscall was the reason.

[pgera]

I think this is because when you install the plugin under user's home, it get's the context Target Context system_u:object_r:nfs_t:s0. However, if you look at the plugins under /usr/lib64/mozilla/plugins, they have a context of system_u:object_r:lib_t:s0. And a transition to the former is denied. I confirmed that if I place the file under /usr/lib64/mozilla/plugins, it doesn't get denied.

I'm not sure what this means from a general security standpoint though, given that flash is extremely insecure. There is no sandboxing like in chrome, but can selinux make it any more secure ?

[i-rinat]

but can selinux make it any more secure

Yeah, sure. Deny everything by default and allow only those parts that are required.

For example, you could deny free filesystem access. Freshplayerplugin requires files in ~/.config/freshwrapper-data/ to be accessible for reading and writing, but doesn't need to be able to read or write anywhere else. It may require reading and writing if you use swf's that open files, but you can limit it to ~/Uploads, for example. Same for other bits. It's the same as for any other application.

[i-rinat]

I believe hardening policies are tightly coupled with the way a particular distribution is organized. So it's not feasible to even try to create security profiles in project code itself.