inotify_rm_watch behavior

inotify_rm_watch behavior

[Eduardo Madeira Fleury]

Hey all,

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.

Regards,
-- 
Eduardo M. Fleury
IBM Linux Technology Center Brazil
Mobile: +55-19-81224410
email/sametime: efleury@br.ibm.com

Re: inotify_rm_watch behavior

[Stephen Smalley]

On Mon, 2006-09-11 at 15:05 -0300, Eduardo Madeira Fleury wrote:
> Hey all,
> 
> 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.

The inotify calls and inotifyfs came up earlier (in June) on
redhat-lspp, subject was "Syscalls questions".

As I noted then, the only object that would get the creator's label is
the struct file (open file description) allocated for the inotify
instance, and the only SELinux check that would be relevant would be the
fd use permission check applied when a descriptor is used, inherited, or
received by a process in a different label.  The lack of MLS checking is
due to the lack of a MLS constraint on fd use in the policy.  That is
what needs to be fixed.  

-- 
Stephen Smalley
National Security Agency

Re: inotify_rm_watch behavior

[Amy Griffis]

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.

Amy

Re: inotify_rm_watch behavior

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency

Re: inotify_rm_watch behavior

[Amy Griffis]

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.

Amy

Re: Re: inotify_rm_watch behavior

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency

Re: [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

Re: [redhat-lspp] Re: inotify_rm_watch behavior

[Stephen Smalley]

On Tue, 2006-09-12 at 09:45 -0400, Stephen Smalley wrote:
> 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.

BTW, the closest equivalent in the TE policy is the 'privfd' attribute
and the domain_interactive_fd() and domain_use_interactive_fd()
interfaces.

-- 
Stephen Smalley
National Security Agency