question re: mount_t context and network I/O

[Christopher Allen Wing]

Hello,

I have a question regarding the mount_t context on RHEL5 (but for my 
purposes the recent Fedora SELinux policies are equally relevant).

I am having a problem where occasionally the 'umount' binary hangs because 
the filesystem being unmounted (OpenAFS) tries to do network I/O as part 
of the kernel code path triggered by the umount() system call.

The actual audit messages in the log look like this:

 	audit(1199237877.841:1837): avc:  denied  { write } for  pid=29174 comm="umount" lport=7001 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=udp_socket


What's happening here, as far as I can tell, is that the openafs 
filesystem (kernel code) tries to do some network I/O from inside the 
umount() system call.  Because this happens in the context of the umount 
process itself, SELinux applies the same restrictions that it would have 
if umount had deliberately used sockets itself.

(The UDP socket in question, bound to port 7001, would have been created 
at the time that the openafs filesystem was initialized)



My question is:

What does the current SELinux policy (e.g. targeted policy) on Fedora do 
for the case of NFS and cifs, for the mount_t context?  Can mount/umount 
perform any network I/O, or is this restricted?



Thanks,

Chris Wing
wingc at umich.edu