On 05/08/2009 08:27 AM, Stephen Smalley wrote:
On Thu, 2009-05-07 at 20:51 -0700, Casey Schaufler wrote:
Serge E. Hallyn wrote:
Quoting Eric Paris (eparis@xxxxxxxxxx):
3) I've also heard it hinted that we could do this with audit by just
having audit drop the denials that include the access(2) syscall and the
scontext and tcontext for the slew of things the SELinux policy writers
know we are not interested in. And while it seems good, now we have
What is the difference whether an attacker does access(2) to check for
/etc/shadow rights, or does a failed open()?
I have been studiously ignoring the discussions on the SELinux list because
in the end it really doesn't matter, as Serge (appears to) point out here.
The access() system call was a major thorn in the side of the POSIX security
working group because its behavior is not really very rational. By design
it does not take into account read-only file systems, ACLs, MAC labels,
TOMOYO policy, or anything other than the mode bits. A successful return
from access() gives you no assurance whatever that if you actually try the
operation it will succeed. My recollection is that every version of
"trusted unix" written treats the system call the same way it would a
call to lstat(), because that's really all it is doing.
Casey, please go read the access(2) / faccessat(2) code in Linux and
then come back to the discussion. It does in fact take into account all
of those things presently (and notes in a comment that SuS v2 requires
that it report a read-only fs).
Reality check.
The biggest reason for this is Nautilus and other GUI tools that open a
directory and look at all of the files in the directory checking their
access. So running as staff_t and using nautilus on the /etc directory
or /bin/directory generates hundreds of AVC indicating that staff_t
tried to read/write/execute every program it is not allowed to execute.
Totally useless and gives the SELinux SUCKS crowd more ammunition. If
the MLS people want to treat ACCESS==OPEN then we are going to have a
big boolean/tunable flag for their paranoia. For everyone else. Lets
try to figure out when an application is actually doing something evil.
Currently pam libraries and kerberos libraries run access checks that
cause us to DONTAUDIT reads of /etc/shadow and WRITES of /etc/krb5.conf
To pretty critical Security files. So any app that uses kerberos
(getpw) call and every app that uses PAM Authentication can try to read
/etc/shadow and write /etc/krb5.conf without us knowing.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
