On Sun, Feb 20, 2011 at 5:54 PM, Scott Gifford <sgifford@suspectclass.com> wrote:
[ ... ] 
I think I can automatically generate a unique category set from a PID by using two MCS categories to represent each bit of the PID, the first for a 0-bit and the second for a 1-bit.  That will take 32 categories for a 16-bit PID, which seems reasonable.

OK, I've got this working now, each PID gets a unique set of MCS categories, and so HTTPD child processes canot read each other's process information.

They do have to share files sometimes, so I designated c0 for that, and made sure the processes are always in c0.  Now if something should be shared, it should remove all groups besides c0, and it will be shareable.

I expected to do this through file mapping in my module's .fc file, like this:

/var/www/portal_auth(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,c0)

But when new files are created in /var/www/portal_auth, they still have all of the PID-specific categories, in addition to c0.

To make this work, I had to grant { setattr relabelfrom relabelto } to my Web app and make a call to setxattr to change the category on shared files.

That works, but it seems like it would be simpler and more secure to do this through file mappings in my modules .fc file.

Is there a mistake in my file context configuration above somewhere?  Or am I misunderstanding how categories are applied from file context rules?

Thanks for any tips,

------Scott.