Dan Walsh's Blog

Got SELinux?

I am going on a trip tomorrow, I went to the Jet Blue web site to print my boarding pass. The Jet Blue site has what I believe is a java application running in the browser that displays your boarding pass. I pressed the "Print" button on the screen and a print dialog came up, without any printers, and the "Print" button grayed out. I did not notice the, setroubleshoot warning in gnome 3. Figuring the print application was just broken, I decided to select print from the browser. Sadly the browser printed a blank page. I then bad mouthed Firefox/Linux printing.

Mia Culpa

I noticed that I had AVC's that looked like mozilla_plugin_t was trying to getattr on lpr_exec_t. I put mozilla_plugin_t into permissive mode, to find out all the access required.

# semanage permissive -a mozilla_plugin_t

I went back to Jet Blue and tried to print the boarding pass again. This time the printers showed up and I was able to print my boarding pass.

Now I had AVC's that indicated mozilla_plugin_t was executing lpr_exec_t. Also lpr was connecting to the cups and gnome-keyring daemon.

Should I transition or add allow rules for mozilla_plugin_t?

As a policy writer I had to choice whether to allow mozilla_plugin_t all of these accesses or have mozilla_plugin_t transition to the lpr_t domain when it executes /usr/bin/lpr. These decisions are key to writing good security policy. My rule of thumb is if the domain i would transition to is very powerful, I hesitate to transition. Especially if the parent application requires limited access when executing the child. For example a user can run rpm in their current domain (staff_T) to list all rpm packages, while if I allowed them to transition to the rpm_t domain, they would be allowed install rpm packages. In the mozilla_plugin_t case the advantage of transitioning to lpr_t allows me to continue to prevent mozilla plugins from talking directly to the cups server and the gnome-keyring and lpr_t is a very limited domain, so I chose to transition.

My initial policy looked like this:

policy_module(mypol, 1.0)

require { type mozilla_plugin_t;}lpd_domtrans_lpr(mozilla_plugin_t)

Now I tried to print the boarding pass again, and now I had AVC's that stated lpr_t was trying to connect to keyring.

audit2allow -R indicated that I should use:

gnome_stream_connect_gkeyringd(lpr_t)

audit2allow also showed that I was failing on Roles Based Access Control (RBAC). Users seldom see these types of errors. They show up in the log file as SELINUX_ERR rather then AVC.

Notice how I am transitioning from mozilla_plugin_t to lpr_t. This does not mean staff_t will transition to lpr_t when running /usr/bin/lpr. In fact, staff_t executes lpr in the staff_t domain, since the staff_t domain has the ability to connect to the cups and gnome-keyring daemons.

But when staff_t executes a firefox plugin, the plugin will transition to a locked down domain mozilla_plugin_t. When the mozilla_plugin_t plugin executes /usr/bin/lpr, the lpr command will transition to the lpr_t domain.

Printing now works well. Now I can remove the permissive flag from mozilla_plugin_t.

# semanage permissive -d mozilla_plugin_t

I have added all these rules into Fedora 17 policy, it should show up in the next policy update.

This is why I live in Rawhide, I want to find problems before users do.