On 07/11/13 10:57, David Crick wrote:
> On Wed, Nov 6, 2013 at 6:01 AM, Steven Haigh <[log in to unmask]> wrote:
>> As part of your security policy - how do you test that SELinux is
>> actually doing what it is supposed to?
>>
>> Apart from the obvious DENIED messages that it gives off, there doesn't
>> seem to be any way to check that it will actually stop unexpected access
>> to various system components.
>>
>> Is there anything further than 'well, its enabled!'?
> 
> 07 Nov 2007: Enterprise Linux 5.0 to 5.1 risk report
> (https://www.awe.com/mark/blog/200711071924.html)
> 
> An update to Samba (May) where a remote attacker could cause a heap
> overflow. In addition to ExecShield making this harder to exploit, the
> impact of any sucessful exploit would be reduced as Samba is
> constrained by an SELinux targeted policy (enabled by default).
> 
> 
> 26 May 2008: Enterprise Linux 5.1 to 5.2 risk report
> (https://www.awe.com/mark/blog/200805262100.html)
> 
> An update to OpenPegasus (January), where a remote attacker who can
> connect to OpenPegasus could cause a buffer overflow. The Red Hat
> Security Response Team believes that it would be hard to remotely
> exploit this issue to execute arbitrary code, due to the default
> SELinux targeted policy, and the default SELinux memory protection
> tests.
> 
> Two updates to Samba (November, December) where a remote attacker who
> can connect to the Samba port could cause buffer overflows. In
> addition to ExecShield making this harder to exploit, the impact of
> any sucessful exploit would be reduced as Samba is constrained by an
> SELinux targeted policy (enabled by default).
> 
> 
> 20 Jan 2009: Enterprise Linux 5.2 to 5.3 risk report
> (https://www.awe.com/mark/blog/2009012017.html):
> 
> An update to Samba (May), where a remote attacker who can connect and
> send a print request to a Samba server could cause a heap overflow.
> The Red Hat Security Response Team believes it would be hard to
> remotely exploit this issue to execute arbitrary code due to the
> default enabled SELinux targeted policy and the default enabled
> SELinux memory protection tests. We are not aware of any public
> exploit for this issue.
> 

While this is interesting, it doesn't provide any methods for auditing
selinux rules.

-- 
Steven Haigh

Email: [log in to unmask]
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299