On 05/12/2011 04:31 PM, Orion Poplawski wrote:
> On 05/12/2011 03:17 PM, Orion Poplawski wrote:
>> On 05/12/2011 03:04 PM, Orion Poplawski wrote:
>>> I'm just trying out openafs on SL6 and ran into the following starting the afs
>>> daemon:
>>>
>>> Starting AFS client.....
>>> afsd: some file missing or bad in /usr/vice/etc
>> Turns out this was caused by following the quick start guide and linking
>> /usr/afs/etc/{CellServDB,ThisCell} to /usr/vice/etc. Just copying the files
>> allows everything to work with SELinux enforcing.
>>
> Spoke too soon.  Lots of denials on the server side of things.  Is there any
> expectation that you can run openafs in enforcing mode?
>
Hi Orion,

While I can't promise this as a true fix, and Stephan Wiesand is aiming 
in the right area with his comments, I've had some luck writing my own 
seLinux policies in the past for completely unrelated and much less 
complex applications.  I've never tried on something as complex as AFS.  
It can be a lot of work, but if you need SL6 and AFS under seLinux, this 
may be your fastest solution.

Not having access to an AFS server, I can't make many suggestions on 
specifics.

The "extra short" process is to, temporarily, place the system in 
Permissive mode (setenforce 0) generate all the audit errors you can for 
AFS, and run audit2allow (yum install policycoreutils-python ; man 
audit2allow ; audit2allow -h ; mkdir -p /etc/selinux/custom ; cat <my 
AFS audit log errors only> | audit2allow -m custom_afs > 
/etc/selinux/custom/custom_afs.te).  Alas this then requires figuring 
out how to reconcile the changes with the existing AFS module, for which 
I'm not sure I can help.  After the .te file doesn't conflict with 
existing settings or open unintended access (I say this like that is the 
easy part - its really not.  You'll need to read the current AFS policy, 
edit the generated one to extend the current policy - without rigging it 
so that future updates to the SL AFS make things confusing on your end.  
Also I've never discovered a sufficiently clean way of documenting 
custom seLinux changes.  If you are like me, you will forget that you 
did this at the least opportune time.), simply checkmodule (cd 
/etc/selinux/custom/ ; checkmodule -M -m -o custom_afs.mod 
custom_afs.te), package the module (cd /etc/selinux/custom ; 
semodule_package -o custom_afs.pp -m custom_afs.mod), and then load it 
(cd /etc/selinux/custom ; semodule -i custom_afs.pp).  Once loaded, 
test, test, test, and test again.  The .pp file can be copied to any 
system sharing a policy version (ie 
selinux-policy-targeted-3.7.19-54.el6_0.5.noarch)

The terribly vague paragraph above represents a serious time investment 
(last time I tried to extend a policy it was a few solid day; though I 
doubt anyone is as terrible at it as I so YMMV) and may not be worth it 
to you at this time.  If you are able to get a working extension to the 
AFS policy, I'm certain the community would love to see it.

If you'd rather spare yourself the hours of frustration, and possible 
unexpected downtime (loading a syntactically valid module, but a "bad" 
one can require a reboot before things start working right again.  I've 
only done it once, and that in 2002, so this might not happen to you), 
I'd return to Stephan's comment.  SL 5 is a wonderful build.  If you're 
AFS system is in production - or will be soon - trial and error seLinux 
experiments are not wise.

Pat