On 2014-01-02, at 15:34, Aaron K. Reffett <[log in to unmask]> wrote:

> Unrelated: openafs-1.6.5.1 SRPM has not been pushed to 6.5/SRPMS/sl6
> 
> After updating to selinux-policy 3.7.19-231 our AFS server processes failed to start with a slew of AVCs in the audit.log. There appears to be a multitude of issues with the AFS SELinux policy shipped by TUV which were triggered by this update.  I set our servers in to permissive which resolved allowed the processes to come up but I'm not sure how to approach a real fix for this issue.
> 
> My initial question is this: was AFS ever supposed to run confined to begin with?

The client should be ok. The servers never worked when running confined.

>  I don't think it was, as files created by the processes themselves before this policy were labeled with the unconfined_u user.  If they weren't, a workaround may be to reset the server executables to bin_t to prevent them from transitioning to confined contexts.

The openafs-server package will set the afs-server init script to unconfined_exec_t. I guess the latest update relabeled that file. We should probably use semanage fcontext to make that change more permanent. Since the policy doesn't care for /etc/rc.d/init.d/afs-server (it's SL specific), this may actually be quite reliable.

Of course it would be great to have the servers running confined, but as you pointed out the policy is not up to date. Besides buserver and the demand attach variants of several server processes, it also lacks support for at least salvageserver and the *sync.sock sockets. It may work for OpenAFS 1.4, and that's probably what it was created for.

Fixing things up may take nothing more than a couple of "semanage fcontext -a" and setting a few booleans (see afs_selinux(8) ) or maybe implementing a relatively simple policy module. We could do that. I see two major problems though:

1) Getting all the corner cases right. You really don't want SELinux to kick in when a server or other process (like the salvager) is running an unusual code path because it's trying to recover from some error or other unusual condition. This could cause loss or corruption of data, wedge the databases, unnecessarily tear down the service, etc. Catching all such cases by testing is just impossible. Thus, such a policy extension would have to be implemented by someone with a deep knowledge of OpenAFS' inner workings. I wouldn't dare.

2) Long term maintenance. With every policy update, someone (again, with the same deep AFS knowledge) would have to check for possible impact on AFS server operation. With updates being rather frequent, and even every feature/bugfix  update ending up in security immediately, I think that's just not feasible - unless someone is willing to pay for it.

Thus, IMHO, running the servers unconfined is the only realistic solution. We probably should do better here.

	Stephan


> SELinux fs contexts greped for afs:
> 
> /afs                                               directory          system_u:object_r:mnt_t:s0 
> /etc/rc\.d/init\.d/afs                             regular file       system_u:object_r:afs_initrc_exec_t:s0 
> /etc/rc\.d/init\.d/openafs-client                  regular file       system_u:object_r:afs_initrc_exec_t:s0 
> /usr/afs/bin/bosserver                             regular file       system_u:object_r:afs_bosserver_exec_t:s0 
> /usr/afs/bin/fileserver                            regular file       system_u:object_r:afs_fsserver_exec_t:s0 
> /usr/afs/bin/kaserver                              regular file       system_u:object_r:afs_kaserver_exec_t:s0 
> /usr/afs/bin/ptserver                              regular file       system_u:object_r:afs_ptserver_exec_t:s0 
> /usr/afs/bin/salvager                              regular file       system_u:object_r:afs_fsserver_exec_t:s0 
> /usr/afs/bin/vlserver                              regular file       system_u:object_r:afs_vlserver_exec_t:s0 
> /usr/afs/bin/volserver                             regular file       system_u:object_r:afs_fsserver_exec_t:s0 
> /usr/afs/db                                        directory          system_u:object_r:afs_dbdir_t:s0 
> /usr/afs/db/ka.*                                   regular file       system_u:object_r:afs_ka_db_t:s0 
> /usr/afs/db/pr.*                                   regular file       system_u:object_r:afs_pt_db_t:s0 
> /usr/afs/db/vl.*                                   regular file       system_u:object_r:afs_vl_db_t:s0 
> /usr/afs/etc(/.*)?                                 all files          system_u:object_r:afs_config_t:s0 
> /usr/afs/local(/.*)?                               all files          system_u:object_r:afs_config_t:s0 
> /usr/afs/logs(/.*)?                                all files          system_u:object_r:afs_logfile_t:s0 
> /usr/sbin/afsd                                     regular file       system_u:object_r:afs_exec_t:s0 
> /usr/vice/cache(/.*)?                              all files          system_u:object_r:afs_cache_t:s0 
> /usr/vice/etc/afsd                                 regular file       system_u:object_r:afs_exec_t:s0 
> /var/cache/afs(/.*)?                               all files          system_u:object_r:afs_cache_t:s0 
> /vicepa                                            all files          system_u:object_r:afs_files_t:s0 
> /vicepb                                            all files          system_u:object_r:afs_files_t:s0 
> /vicepc                                            all files          system_u:object_r:afs_files_t:s0
> 
> Only some of the AFS executables are labeled with execution contexts, notably da{fileserver,volserver,salvager} are not labeled, nor is buserver.
> 
> Attached is a sampling of the audit logs from my DB and FS servers which shows many denied actions from the various AFS processes.
> 
> ~Aaron
> <afs-db-server-avc.txt><afs-fs-server-avc.txt>

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany