[redhat-lspp] Re: inotify_rm_watch behavior

[Darrel Goeddel]

Stephen Smalley wrote:
> On Mon, 2006-09-11 at 15:34 -0400, Amy Griffis wrote:
> 
>>Stephen Smalley wrote:  [Mon Sep 11 2006, 03:15:59PM EDT]
>>
>>>On Mon, 2006-09-11 at 14:49 -0400, Amy Griffis wrote:
>>>
>>>>Eduardo Madeira Fleury wrote:  [Mon Sep 11 2006, 02:05:24PM EDT]
>>>>
>>>>>I'm doing some tests and currently inotify_rm_watch is not performing any 
>>>>>permission checks, i.e., an ordinary user can remove a watch set by root on a 
>>>>>file with root:root 400 permission.
>>>>>
>>>>>Is this the expected behavior? Seems like neither MAC nor MLS checks are being 
>>>>>done.
>>>>
>>>>Yes.  As I understand it, an inotify watch is not a data object, and
>>>>so does not require DAC or MAC checks.
>>>
>>>Not sure I follow the rationale for MAC.  Process in security context C1
>>>creates an inotify instance, adds some watches to files/directories it
>>>can read (read permission checked between C1 and file context upon
>>>inotify_add_watch), provides the instance descriptor to a process in
>>>security context C2 via execve inheritance or local IPC.  Process in
>>>security context C2 can now read events on those watched
>>>files/directories even if it lacks direct read permission to them and
>>>can add and remove watches on the inotify instance, indirectly signaling
>>>the C1 process via the shared inotify instance.
>>>
>>>All of which would be avoided if the MLS policy included a constraint on
>>>fd use permission, thereby preventing such sharing of inotify instances
>>>among processes in different levels except for trusted subjects or
>>>objects identified by a type attribute.
>>
>>Agreed.  I was trying to say that there shouldn't be a constraint on
>>the inotify watch itself.  Until I saw your mail, I wasn't aware that
>>there aren't currently any constraints on sharing inotify instances.
> 
> 
> Yes, I pointed this out during the "Syscalls questions" discussion back
> in June.  Not sure why no one bothered adding such a constraint to MLS
> policy at the time.  It would be something like:
> policy/mls:
> 	# No sharing of open file descriptions between levels unless
> 	# the process type is authorized to use fds created by 
> 	# other levels (mlsfduse) or the fd type is authorized to
> 	# shared among levels (mlsfdshare). 
> 	mlsconstrain fd use ( l1 eq l2 or t1 == mlsfduse or t2 == mlsfdshare);
> 
> policy/modules/kernel/mls.te:
> 	attribute mlsfduse; 
> 	attribute mlsfdshare;
> 
> policy/modules/kernel/mls.if:
> 	interface(`mls_fd_use',`
>         gen_require(`
>                 attribute mlsfduse;
>         ')
> 
>         typeattribute $1 mlsfduse;
> 	')
> 
> 	interface(`mls_fd_share',`
>         gen_require(`
>                 attribute mlsfdshare;
>         ')
> 
>         typeattribute $1 mlsfdshare;
> 	')
> 
> 
> And then one would add mls_fd_use() and mls_fd_share() as appropriate to
> types in the policy, e.g.
> policy/modules/system/selinuxtil.te:
> 	mls_fd_share(newrole_t)
> 
> and likewise for login and friends.
> 
> Naturally, one would need to exercise the system quite a bit to work out
> exactly what domains require such use/sharing.

The approach outlined above looks good.  

-- 

Darrel