inotify_rm_watch behavior
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,
Signature · 4 lines
Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email/sametime: [email protected]
Quoted 8 lines · Eduardo Madeira Fleury
Hey all,
I'm doing some tests and currently
inotify_rm_watchis 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.
Signature · 2 lines
Stephen Smalley National Security Agency
Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT]
Quoted 6 lines
I'm doing some tests and currently
inotify_rm_watchis 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
Quoted 10 lines · Amy Griffis
Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT]
Quoted 6 lines
I'm doing some tests and currently
inotify_rm_watchis 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.
Signature · 2 lines
Stephen Smalley National Security Agency
Stephen Smalley wrote: [Mon Sep 11 2006, 03:15:59PM EDT]
Quoted 22 lines · Amy Griffis
Quoted 10 lines
Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT]
Quoted 6 lines
I'm doing some tests and currently
inotify_rm_watchis 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.
Quoted 4 lines
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
Quoted 23 lines · Amy Griffis
Stephen Smalley wrote: [Mon Sep 11 2006, 03:15:59PM EDT]
Quoted 22 lines · Amy Griffis
Quoted 10 lines
Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT]
Quoted 6 lines
I'm doing some tests and currently
inotify_rm_watchis 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.
Quoted 8 lines
Quoted 4 lines
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.
Signature · 2 lines
Stephen Smalley National Security Agency
Quoted 72 lines · Stephen Smalley
Quoted 23 lines · Amy Griffis
Stephen Smalley wrote: [Mon Sep 11 2006, 03:15:59PM EDT]
Quoted 21 lines · Amy Griffis
Quoted 9 lines
Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT]
Quoted 3 lines
I'm doing some tests and currently
inotify_rm_watchis 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.Quoted 8 lines
Quoted 4 lines
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()andmls_fd_share()as appropriate to types in the policy, e.g. policy/modules/system/selinuxtil.te:
mls_fd_share(newrole_t)
Quoted 4 lines
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.
Signature · 1 line
Darrel
Quoted 37 lines · Stephen Smalley
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()andmls_fd_share()as appropriate to types in the policy, e.g. policy/modules/system/selinuxtil.te:
mls_fd_share(newrole_t)
Quoted 4 lines
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.
Signature · 2 lines
Stephen Smalley National Security Agency