Re: SELinux and access(2), we want to know.

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

 



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.

--
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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux