danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Add to Memories Share Next Entry
Eating my own dogfood.
danwalsh
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.

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.c1023 tcontext=staff_u:staff_r:lpr_t:s0-s0:c0.c1023 tclass=unix_stream_socket

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:

policy_module(mypol, 1.0)
require {
    type mozilla_plugin_t;
    type lpr_t;
    role staff_r;
}
lpd_domtrans_lpr(mozilla_plugin_t)
role staff_r types lpr_t;
gnome_stream_connect_gkeyringd(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.

That's weird... /usr/bin/lpr shouldn't be talking to GNOME Keyring as far as I'm aware.

Yes it is. Not sure what is going on.

Could it be using some pam plugin? Some shared library?

You are viewing danwalsh