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