access(2) vs. SELinux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Per [1], the fact that SELinux applies the same read/write/execute
checks in response to access(2) calls as it does for an actual open(2)
for read/write or execve(2) for execute leads to huge numbers of
spurious denials for applications such as nautilus that probe all files
being listed.  dontaudit'ing of these denials is viewed as unacceptable
as Dan wants to be able to see such denials upon the actual open(2) or
execve(2) attempts.

If access(2) only returned the result of the DAC access checks and e.g.
only checked getattr permission on access(2) calls (similar to stat(2)),
then the read/write/execute MAC denials would not happen, but that would
likely break the behavior of existing applications/libraries that use
access(2) to decide whether to follow a privileged code path or fall
back on an unprivileged code path (e.g. kerberos libraries).

Other suggested proposals included:
- Using the _noaudit interface to suppress auditing of the
read/write/execute checks when checking for access(2), although this
requires reworking the underlying implementation so that we can
distinguish access(2) from open(2) checking.  However, this could lead
to silent failure of applications with no way to obtain any audit
messages, and would provide an obvious way to probe for access without
triggering audit.

- Using a different class or set of permissions when checking for
access(2), likewise requiring reworking the underlying implementation so
that we can distinguish the checking from open(2).  Then one could
choose to use dontaudit rules to suppress the access(2) checking w/o
suppressing the open(2) checking.  However, this could present a major
consistency problem between what access(2) reports and what is actually
allowed upon open(2) or execve(2).

Thoughts?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=495211


-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux