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:
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:
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.
type=SELINUX_ERR msg=audit(1332420617.119:909): security_compute_sid: invalid context staff_u:staff_r:lpr_t:s0-s0:c0.c1023 for scontext=staff_u:staff_r:lpr_t:s0-s0:c0.c
This AVC is basically saying the staff_u:staff_r:lpr_t:s0-s0:c0.c1023 is an invalid label.
Hard to tell from this error what is wrong, but luckily audit2allow translates this into:
role staff_r types lpr_t;
Since I run with the staff_r role, I had to add an RBAC rule that would allow staff_r role to reach the lpr_t type.
My final policy looks like:
role staff_r types lpr_t;
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.