From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: SELinux for auditing Date: Wed, 31 Jan 2007 00:11:30 +0000 Message-ID: <1170202290.4168.14.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0714095318==" Return-path: Received: from [10.247.111.180] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0V0BLtj012550 for ; Wed, 31 Jan 2007 00:11:24 GMT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============0714095318== Content-Type: multipart/alternative; boundary="=-De36c5nFEoFhaoK8VBVr" --=-De36c5nFEoFhaoK8VBVr Content-Type: text/plain Content-Transfer-Encoding: 7bit I have a couple of requirements which on the face of it don't seem simple to achieve with auditctl. These are: * Audit changes to executables * Audit changes to configuration files I'll concentrate on the former as it's more obviously problematic. I believe this would require putting a watch explicitly on every executable in the system. If this isn't correct, please correct me and this problem goes away. Assuming it is, though, I don't believe this is a practical solution. It occurs to me that this might be more easily achieved with SELinux. As a test, I made the following small change to the unconfined domain of the RHEL 4 targeted policy macros/global_macros.te: define(`executable_files', `{ exec_type sbin_t bin_t lib_t shlib_t ld_so_t }') #allow $1 file_type:dir_file_class_set *; allow $1 file_type:dir_file_class_set ~execute; allow $1 executable_files:dir_file_class_set *; auditallow $1 executable_files:dir_file_class_set { create write rename setattr append relabelfrom }; This does 2 things. Firstly it enforces that the system won't execute files which aren't labelled with an executable type. This is really just to make sure everything is caught by the second rule, which is to audit changes to executables. To make this thorough, you'd have to go through everywhere else execute is granted in other domains. However, I'm worried I might be stepping outside design intentions. Is the above a good idea? Is using SELinux for writing auditing rules a good idea in general? uIs there a better way to achieve this and similar requirements which affect a potentially large class of file? Thanks, Matt -- Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 --=-De36c5nFEoFhaoK8VBVr Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit I have a couple of requirements which on the face of it don't seem simple to achieve with auditctl. These are:

* Audit changes to executables
* Audit changes to configuration files

I'll concentrate on the former as it's more obviously problematic. I believe this would require putting a watch explicitly on every executable in the system. If this isn't correct, please correct me and this problem goes away. Assuming it is, though, I don't believe this is a practical solution.

It occurs to me that this might be more easily achieved with SELinux. As a test, I made the following small change to the unconfined domain of the RHEL 4 targeted policy macros/global_macros.te:

define(`executable_files', `{ exec_type sbin_t bin_t lib_t shlib_t ld_so_t }')

#allow $1 file_type:dir_file_class_set *;
allow $1 file_type:dir_file_class_set ~execute;
allow $1 executable_files:dir_file_class_set *;

auditallow $1 executable_files:dir_file_class_set { create write rename setattr append relabelfrom };

This does 2 things. Firstly it enforces that the system won't execute files which aren't labelled with an executable type. This is really just to make sure everything is caught by the second rule, which is to audit changes to executables. To make this thorough, you'd have to go through everywhere else execute is granted in other domains.

However, I'm worried I might be stepping outside design intentions. Is the above a good idea? Is using SELinux for writing auditing rules a good idea in general? uIs there a better way to achieve this and similar requirements which affect a potentially large class of file?

Thanks,

Matt

-- 
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

--=-De36c5nFEoFhaoK8VBVr-- --===============0714095318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0714095318==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: SELinux for auditing Date: Thu, 1 Feb 2007 09:36:59 -0500 Message-ID: <200702010936.59578.sgrubb@redhat.com> References: <1170202290.4168.14.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1170202290.4168.14.camel@localhost.localdomain> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tuesday 30 January 2007 19:11, Matthew Booth wrote: > I have a couple of requirements which on the face of it don't seem > simple to achieve with auditctl. These are: > > * Audit changes to executables > * Audit changes to configuration files > > I'll concentrate on the former as it's more obviously problematic. I > believe this would require putting a watch explicitly on every > executable in the system. Assuming current generation of audit code... auditctl -a exit,always -F perm=w -F obj_type=sbin_t -k executables auditctl -a exit,always -F perm=w -F obj_type=bin_t -k executables auditctl -a exit,always -F perm=w -F obj_type=lib_t -k executables auditctl -a exit,always -F perm=w -F obj_type=shlib_t -k executables > If this isn't correct, please correct me and this problem goes away. Try the above. "ausearch -k executables" would let you find these events. > This does 2 things. Firstly it enforces that the system won't execute > files which aren't labelled with an executable type. This might not be a bad thing to include even if the audit rules above solve your problem. > However, I'm worried I might be stepping outside design intentions. Is > the above a good idea? I'm hoping the audit system can meet any audit requirements. If not we need to work some more at it. > Is using SELinux for writing auditing rules a good idea in general? If there are shortcomings in the audit system that you can solve another way, I guess you have no choice. But we'd like to know that people cannot use the audit system for its intended purpose. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smalley Subject: Re: SELinux for auditing Date: Thu, 01 Feb 2007 09:59:00 -0500 Message-ID: <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> References: <1170202290.4168.14.camel@localhost.localdomain> <200702010936.59578.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200702010936.59578.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thu, 2007-02-01 at 09:36 -0500, Steve Grubb wrote: > On Tuesday 30 January 2007 19:11, Matthew Booth wrote: > > I have a couple of requirements which on the face of it don't seem > > simple to achieve with auditctl. These are: > > > > * Audit changes to executables > > * Audit changes to configuration files > > > > I'll concentrate on the former as it's more obviously problematic. I > > believe this would require putting a watch explicitly on every > > executable in the system. > > Assuming current generation of audit code... > > auditctl -a exit,always -F perm=w -F obj_type=sbin_t -k executables Hmmm...on FC6, that yields an error from auditctl: key option needs a watch or syscall given prior to it Dropping the -k option avoids the error message, but overwriting a bin_t file doesn't generate any audit message. Similarly, adding a -S open avoids the error message while retaining the -k, but overwriting a bin_t file doesn't generate any audit message. Not sure where the problem lies there. Also, he mentioned RHEL 4 as his platform, so I would tend to think that his kernel and auditctl wouldn't support this anyway. So he may be limited to using auditallow statements in policy, which is certainly legitimate use of them (although I understand your goal of centralizing audit configuration). -- Stephen Smalley National Security Agency From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: SELinux for auditing Date: Thu, 1 Feb 2007 10:40:48 -0500 Message-ID: <200702011040.48405.sgrubb@redhat.com> References: <1170202290.4168.14.camel@localhost.localdomain> <200702010936.59578.sgrubb@redhat.com> <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Stephen Smalley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday 01 February 2007 09:59, Stephen Smalley wrote: > > Assuming current generation of audit code... > > > > auditctl -a exit,always -F perm=w -F obj_type=sbin_t -k executables > > Hmmm...on FC6, that yields an error from auditctl: > key option needs a watch or syscall given prior to it Ooops, that should be: auditctl -a exit,always -F perm=w -F obj_type=bin_t -F key=executable > Dropping the -k option avoids the error message, but overwriting a bin_t > file doesn't generate any audit message. Similarly, adding a -S open > avoids the error message while retaining the -k, but overwriting a bin_t > file doesn't generate any audit message. Not sure where the problem > lies there. OK, we should look into this. > Also, he mentioned RHEL 4 as his platform, so I would tend to think that > his kernel and auditctl wouldn't support this anyway. If so, it won't. > So he may be limited to using auditallow statements in policy, which is > certainly legitimate use of them (although I understand your goal of > centralizing audit configuration). Well, not just centralizing configuration, but that its actually fit for its purpose. :) -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: Re: SELinux for auditing Date: Fri, 02 Feb 2007 12:37:17 +0000 Message-ID: <1170419837.6772.14.camel@localhost.localdomain> References: <1170202290.4168.14.camel@localhost.localdomain> <200702010936.59578.sgrubb@redhat.com> <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1826833166==" Return-path: Received: from [192.168.250.101] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l12Jp2j5024516 for ; Fri, 2 Feb 2007 19:51:04 GMT In-Reply-To: <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1826833166== Content-Type: multipart/alternative; boundary="=-yJXNFZXyUTCdnQ+8zoyQ" --=-yJXNFZXyUTCdnQ+8zoyQ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2007-02-01 at 09:59 -0500, Stephen Smalley wrote: > Also, he mentioned RHEL 4 as his platform, so I would tend to think that > his kernel and auditctl wouldn't support this anyway. So he may be > limited to using auditallow statements in policy, which is certainly > legitimate use of them (although I understand your goal of centralizing > audit configuration). It is for RHEL 4, so the above won't work. How much of the functionality is in userspace, and how much requires extra kernel bits? In short, can I recompile the RHEL5 auditd for RHEL4 and expect to get additional functionality? Matt -- Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 --=-yJXNFZXyUTCdnQ+8zoyQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Thu, 2007-02-01 at 09:59 -0500, Stephen Smalley wrote:

Also, he mentioned RHEL 4 as his platform, so I would tend to think that
his kernel and auditctl wouldn't support this anyway.  So he may be
limited to using auditallow statements in policy, which is certainly
legitimate use of them (although I understand your goal of centralizing
audit configuration).

It is for RHEL 4, so the above won't work. How much of the functionality is in userspace, and how much requires extra kernel bits? In short, can I recompile the RHEL5 auditd for RHEL4 and expect to get additional functionality?

Matt

-- 
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

--=-yJXNFZXyUTCdnQ+8zoyQ-- --===============1826833166== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1826833166==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: SELinux for auditing Date: Fri, 2 Feb 2007 15:12:32 -0500 Message-ID: <200702021512.32866.sgrubb@redhat.com> References: <1170202290.4168.14.camel@localhost.localdomain> <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> <1170419837.6772.14.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1170419837.6772.14.camel@localhost.localdomain> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Friday 02 February 2007 07:37, Matthew Booth wrote: > How much of the functionality is in userspace, and how much requires extra > kernel bits? The identification of syscalls that becomes an event is done by the kernel. Userspace just send rules into the kernel and records what the kernel sees. > In short, can I recompile the RHEL5 auditd for RHEL4 and expect to get > additional functionality? Not really for 2 reasons. One being that the watch technique is totally different and incompatible between current user space and the old 1.0.x series. The other being that the interesting work is done by the kernel. That said, there is an update to RHEL4 audit (1.0.15-2) that introduces the realtime interface from RHEL5 that should be part of the U5 update. That could be handy for moving events off the machine in realtime. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: SELinux for auditing Date: Fri, 16 Feb 2007 19:14:54 -0500 Message-ID: <200702161914.55018.sgrubb@redhat.com> References: <1170202290.4168.14.camel@localhost.localdomain> <200702010936.59578.sgrubb@redhat.com> <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1170341940.12293.124.camel@moss-spartans.epoch.ncsc.mil> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Stephen Smalley Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday 01 February 2007 09:59:00 Stephen Smalley wrote: > > Assuming current generation of audit code... > > > > auditctl -a exit,always -F perm=3Dw -F obj_type=3Dsbin_t -k executabl= es > > Hmmm...on FC6, that yields an error from auditctl: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0key option needs a watc= h or syscall given prior to it > > Dropping the -k option avoids the error message, but overwriting a bin_= t > file doesn't generate any audit message. This turned out to be a bug in libaudit which was fixed in 1.4.1. It shou= ld=20 work as I stated above when you upgrade. If not, let me know... -Steve