[PATCH 0/2] namespaces: log namespaces per task
by Richard Guy Briggs
I saw no replies to my questions when I replied a year after Aris' posting, so
I don't know if it was ignored or got lost in stale threads:
https://www.redhat.com/archives/linux-audit/2013-March/msg00020.html
https://www.redhat.com/archives/linux-audit/2013-March/msg00033.html
(https://lists.linux-foundation.org/pipermail/containers/2013-March/032063...)
https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html
I've tried to answer a number of questions that were raised in that thread.
The goal is not quite identical to Aris' patchset.
The purpose is to track namespaces in use by logged processes from the
perspective of init_*_ns. The first patch defines a function to list them.
The second patch provides an example of usage for audit_log_task_info() which
is used by syscall audits, among others. audit_log_task() and
audit_common_recv_message() would be other potential use cases.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs). It
could be argued that the inode numbers have now become a defacto interface and
can't change now, but I'm proposing this approach to see if this helps address
some of the objections to the earlier patchset.
There could also have messages added to track the creation and the destruction
of namespaces, listing the parent for hierarchical namespaces such as pidns,
userns, and listing other ids for non-hierarchical namespaces, as well as other
information to help identify a namespace.
There has been some progress made for audit in net namespaces and pid
namespaces since this previous thread. net namespaces are now served as peers
by one auditd in the init_net namespace with processes in a non-init_net
namespace being able to write records if they are in the init_user_ns and have
CAP_AUDIT_WRITE. Processes in a non-init_pid_ns can now similarly write
records. As for CAP_AUDIT_READ, I just posted a patchset to check capabilities
of userspace processes that try to join netlink broadcast groups.
Questions:
Is there a way to link serial numbers of namespaces involved in migration of a
container to another kernel? (I had a brief look at CRIU.) Is there a unique
identifier for each running instance of a kernel? Or at least some identifier
within the container migration realm?
What additional events should list this information?
Does this present any kind of information leak? Only CAP_AUDIT_CONTROL (and
proposed CAP_AUDIT_READ) in init_user_ns can get to this information in the
init namespace at the moment.
Proposed output format:
This differs slightly from Aristeu's patch because of the label conflict with
"pid=" due to including it in existing records rather than it being a seperate
record:
type=SYSCALL msg=audit(1398112249.996:65): arch=c000003e syscall=272 success=yes exit=0 a0=40000000 a1=ffffffffffffffff a2=0 a3=22 items=0 ppid=1 pid=566 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" exe="/usr/lib/systemd/systemd" mntns=5 netns=97 utsns=2 ipcns=1 pidns=4 userns=3 subj=system_u:system_r:init_t:s0 key=(null)
Note: This set does not try to solve the non-init namespace audit messages and
auditd problem yet. That will come later, likely with additional auditd
instances running in another namespace with a limited ability to influence the
master auditd. I echo Eric B's idea that messages destined for different
namespaces would have to be tailored for that namespace with references that
make sense (such as the right pid number reported to that pid namespace, and
not leaking info about parents or peers).
Richard Guy Briggs (2):
namespaces: give each namespace a serial number
audit: log namespace serial numbers
fs/mount.h | 1 +
fs/namespace.c | 1 +
include/linux/audit.h | 7 +++++++
include/linux/ipc_namespace.h | 1 +
include/linux/nsproxy.h | 8 ++++++++
include/linux/pid_namespace.h | 1 +
include/linux/user_namespace.h | 1 +
include/linux/utsname.h | 1 +
include/net/net_namespace.h | 1 +
init/version.c | 1 +
ipc/msgutil.c | 1 +
ipc/namespace.c | 2 ++
kernel/audit.c | 38 ++++++++++++++++++++++++++++++++++++++
kernel/nsproxy.c | 24 ++++++++++++++++++++++++
kernel/pid.c | 1 +
kernel/pid_namespace.c | 2 ++
kernel/user.c | 1 +
kernel/user_namespace.c | 2 ++
kernel/utsname.c | 2 ++
net/core/net_namespace.c | 4 +++-
20 files changed, 99 insertions(+), 1 deletions(-)
10 years, 5 months
Re: [PATCH 0/2] namespaces: log namespaces per task
by James Bottomley
On May 5, 2014 3:36:38 PM PDT, Serge Hallyn <serge.hallyn(a)ubuntu.com> wrote:
>Quoting James Bottomley (James.Bottomley(a)HansenPartnership.com):
>> On Mon, 2014-05-05 at 22:27 +0000, Serge Hallyn wrote:
>> > Quoting James Bottomley (James.Bottomley(a)HansenPartnership.com):
>> > > On Mon, 2014-05-05 at 17:48 -0400, Richard Guy Briggs wrote:
>> > > > On 14/05/05, Serge E. Hallyn wrote:
>> > > > > Quoting James Bottomley
>(James.Bottomley(a)HansenPartnership.com):
>> > > > > > On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs
>wrote:
>> > > > > > > Questions:
>> > > > > > > Is there a way to link serial numbers of namespaces
>involved in migration of a
>> > > > > > > container to another kernel? (I had a brief look at
>CRIU.) Is there a unique
>> > > > > > > identifier for each running instance of a kernel? Or at
>least some identifier
>> > > > > > > within the container migration realm?
>> > > > > >
>> > > > > > Are you asking for a way of distinguishing an migrated
>container from an
>> > > > > > unmigrated one? The answer is pretty much "no" because the
>job of
>> > > > > > migration is to restore to the same state as much as
>possible.
>> > > > > >
>> > > > > > Reading between the lines, I think your goal is to
>correlate audit
>> > > > > > information across a container migration, right? Ideally
>the management
>> > > > > > system should be able to cough up an audit trail for a
>container
>> > > > > > wherever it's running and however many times it's been
>migrated?
>> > > > > >
>> > > > > > In that case, I think your idea of a numeric serial number
>in a dense
>> > > > > > range is wrong. Because the range is dense you're
>obviously never going
>> > > > > > to be able to use the same serial number across a
>migration. However,
>> > > > >
>> > > > > Ah, but I was being silly before, we can actually address
>this pretty
>> > > > > simply. If we just (for instance) add
>> > > > > /proc/self/ns/{ic,mnt,net,pid,user,uts}_seq containing the
>serial number
>> > > > > for the relevant ns for the task, then criu can dump this
>info at
>> > > > > checkpoint. Then at restart it can dump an audit message per
>task and
>> > > > > ns saying old_serial=%x,new_serial=%x. That way the audit
>log reader
>> > > > > can if it cares keep track.
>> > > >
>> > > > This is the sort of idea I had in mind...
>> > >
>> > > OK, but I don't understand then why you need a serial number.
>There are
>> > > plenty of things we preserve across a migration, like namespace
>name for
>> > > instance. Could you explain what function it performs because I
>think I
>> > > might be missing something.
>> >
>> > We're looking ahead to a time when audit is namespaced, and a
>container
>> > can keep its own audit logs (without limiting what the host audits
>of
>> > course). So if a container is auditing suspicious activity by some
>> > task in a sub-namesapce, then the whole parent container gets
>migrated,
>> > after migration we want to continue being able to correlate the
>namespaces.
>> >
>> > We're also looking at audit trails on a host that is up for years.
>We
>> > would like every namespace to be uniquely logged there. That is
>why
>> > inode #s on /proc/self/ns/* are not sufficient, unless we add a
>generation
>> > # (which would end more complicated, not less, than a serial #).
>>
>> Right, but when the contaner has an audit namespace, that namespace
>has
>> a name,
>
>What ns has a name?
The netns for instance.
> The audit ns can be tied to 50 pid namespaces, and
>we
>want to log which pidns is responsible for something.
>
>If you mean the pidns has a name, that's the problem... it does not,
>it
>only has a inode # which may later be re-use.
I still think there's a miscommunication somewhere: I believe you just need a stable id to tie the audit to, so why not just give the audit namespace a name like net? The id would then be durable across migrations.
>> which CRIU would migrate, so why not use that name for the
>> log .. no need for numbers (unless you make the name a number, of
>> course)?
>>
>> James
>
>Sorry if I'm being dense...
No I think our assumptions are mismatched. I just can't figure out where.
James
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
10 years, 6 months
[PATCH] audit: log on the future execution of a path
by Richard Guy Briggs
Here is another attempt at getting closer to auditing on the future execution
of a path.
Storing the dev/inode of the path in the rule won't help us because the path
may not exist yet.
Please see the accompanying userspace patch. I don't expect the userspace
interface to change appreciably unless I've overlooked something important. I
am able to set and get rules as expected.
It will be slow because it has to do a string compare on every sys_execve()
invocation. The compare function uses the process' struct filename *. I'm
guessing a hash of the string could speed that up.
Only problem is, it doesn't work. What assumptions am I making that aren't
valid about the approach in this kernel code?
I also considered adding the path string pointer to the struct audit_field.
Any suggestions?
See: (I'd use the redhat.com/archives/linux-audit links, but they don't link across months.)
"auditing syscalls made 'by' an inode?"
http://comments.gmane.org/gmane.linux.redhat.security.audit/4255
"audit: audit on the future execution of a binary."
http://comments.gmane.org/gmane.linux.redhat.security.audit/4388
"Support for auditing on the actions of a not-yet-executed process."
http://comments.gmane.org/gmane.linux.redhat.security.audit/4389
"Excluding events by command"
http://comments.gmane.org/gmane.linux.redhat.security.audit/4428
Richard Guy Briggs (1):
audit: audit on the future execution of a binary.
include/linux/audit.h | 1 +
include/uapi/linux/audit.h | 2 ++
kernel/auditfilter.c | 35 +++++++++++++++++++++++++++++++++++
kernel/auditsc.c | 35 +++++++++++++++++++++++++++++++++++
4 files changed, 73 insertions(+), 0 deletions(-)
10 years, 6 months
Re: [PATCH 0/2] namespaces: log namespaces per task
by James Bottomley
On Mon, 2014-05-05 at 22:27 +0000, Serge Hallyn wrote:
> Quoting James Bottomley (James.Bottomley(a)HansenPartnership.com):
> > On Mon, 2014-05-05 at 17:48 -0400, Richard Guy Briggs wrote:
> > > On 14/05/05, Serge E. Hallyn wrote:
> > > > Quoting James Bottomley (James.Bottomley(a)HansenPartnership.com):
> > > > > On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs wrote:
> > > > > > Questions:
> > > > > > Is there a way to link serial numbers of namespaces involved in migration of a
> > > > > > container to another kernel? (I had a brief look at CRIU.) Is there a unique
> > > > > > identifier for each running instance of a kernel? Or at least some identifier
> > > > > > within the container migration realm?
> > > > >
> > > > > Are you asking for a way of distinguishing an migrated container from an
> > > > > unmigrated one? The answer is pretty much "no" because the job of
> > > > > migration is to restore to the same state as much as possible.
> > > > >
> > > > > Reading between the lines, I think your goal is to correlate audit
> > > > > information across a container migration, right? Ideally the management
> > > > > system should be able to cough up an audit trail for a container
> > > > > wherever it's running and however many times it's been migrated?
> > > > >
> > > > > In that case, I think your idea of a numeric serial number in a dense
> > > > > range is wrong. Because the range is dense you're obviously never going
> > > > > to be able to use the same serial number across a migration. However,
> > > >
> > > > Ah, but I was being silly before, we can actually address this pretty
> > > > simply. If we just (for instance) add
> > > > /proc/self/ns/{ic,mnt,net,pid,user,uts}_seq containing the serial number
> > > > for the relevant ns for the task, then criu can dump this info at
> > > > checkpoint. Then at restart it can dump an audit message per task and
> > > > ns saying old_serial=%x,new_serial=%x. That way the audit log reader
> > > > can if it cares keep track.
> > >
> > > This is the sort of idea I had in mind...
> >
> > OK, but I don't understand then why you need a serial number. There are
> > plenty of things we preserve across a migration, like namespace name for
> > instance. Could you explain what function it performs because I think I
> > might be missing something.
>
> We're looking ahead to a time when audit is namespaced, and a container
> can keep its own audit logs (without limiting what the host audits of
> course). So if a container is auditing suspicious activity by some
> task in a sub-namesapce, then the whole parent container gets migrated,
> after migration we want to continue being able to correlate the namespaces.
>
> We're also looking at audit trails on a host that is up for years. We
> would like every namespace to be uniquely logged there. That is why
> inode #s on /proc/self/ns/* are not sufficient, unless we add a generation
> # (which would end more complicated, not less, than a serial #).
Right, but when the contaner has an audit namespace, that namespace has
a name, which CRIU would migrate, so why not use that name for the
log .. no need for numbers (unless you make the name a number, of
course)?
James
10 years, 6 months
[PATCH] userspace: audit: log on the future execution of a path
by Richard Guy Briggs
Enable creation of rules to monitor for the execution of a path in the future.
For example, to log occurances of touch(1)ing a file in /tmp, use:
-a always,exit -F dir=/tmp -F exe=/usr/sbin/touch -F key=touch_tmp
The command:
touch /tmp/test
should generate a log message that can be verified by:
ausearch --start recent -k touch_tmp
Similarly, use "exe_children=" in the place of "exe=" to detect the case for
any descendent processes.
Based-on-work-by: Peter Moody <pmoody(a)google.com>
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
trunk/lib/errormsg.h | 2 +-
trunk/lib/fieldtab.h | 2 ++
trunk/lib/libaudit.c | 5 +++++
trunk/lib/libaudit.h | 7 ++++++-
trunk/src/auditctl-listing.c | 8 +++++++-
5 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/trunk/lib/errormsg.h b/trunk/lib/errormsg.h
index a4fea66..8d72bd8 100644
--- a/trunk/lib/errormsg.h
+++ b/trunk/lib/errormsg.h
@@ -51,7 +51,7 @@ static const struct msg_tab err_msgtab[] = {
{ -15, 2, "-F unknown errno -"},
{ -16, 2, "-F unknown file type - " },
{ -17, 1, "can only be used with exit and entry filter list" },
- { -18, 1, "" }, // Unused
+ { -18, 1, "only takes = operator" },
{ -19, 0, "Key field needs a watch or syscall given prior to it" },
{ -20, 2, "-F missing value after operation for" },
{ -21, 2, "-F value should be number for" },
diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h
index c0432cc..245b541 100644
--- a/trunk/lib/fieldtab.h
+++ b/trunk/lib/fieldtab.h
@@ -66,3 +66,5 @@ _S(AUDIT_ARG3, "a3" )
_S(AUDIT_FILTERKEY, "key" )
_S(AUDIT_FIELD_COMPARE, "field_compare" )
+_S(AUDIT_EXE, "exe" )
+_S(AUDIT_EXE_CHILDREN, "exe_children" )
diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c
index 5936c86..509e4be 100644
--- a/trunk/lib/libaudit.c
+++ b/trunk/lib/libaudit.c
@@ -1312,6 +1312,11 @@ int audit_rule_fieldpair_data(struct audit_rule_data **rulep, const char *pair,
case AUDIT_SUBJ_SEN:
case AUDIT_SUBJ_CLR:
case AUDIT_FILTERKEY:
+ case AUDIT_EXE_CHILDREN:
+ case AUDIT_EXE:
+ if ((field == AUDIT_EXE_CHILDREN || field == AUDIT_EXE) &&
+ op != AUDIT_EQUAL)
+ return -18;
if (field == AUDIT_FILTERKEY && !(_audit_syscalladded || _audit_permadded))
return -19;
vlen = strlen(v);
diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h
index 10e3cfc..0233cee 100644
--- a/trunk/lib/libaudit.h
+++ b/trunk/lib/libaudit.h
@@ -251,6 +251,12 @@ extern "C" {
#ifndef AUDIT_FIELD_COMPARE
#define AUDIT_FIELD_COMPARE 111
#endif
+#ifndef AUDIT_EXE
+#define AUDIT_EXE 112
+#endif
+#ifndef AUDIT_EXE_CHILDREN
+#define AUDIT_EXE_CHILDREN 113
+#endif
#ifndef AUDIT_COMPARE_UID_TO_OBJ_UID
#define AUDIT_COMPARE_UID_TO_OBJ_UID 1
@@ -546,4 +552,3 @@ extern void audit_rule_free_data(struct audit_rule_data *rule);
#endif
#endif
-
diff --git a/trunk/src/auditctl-listing.c b/trunk/src/auditctl-listing.c
index a4d5e20..b37d7b2 100644
--- a/trunk/src/auditctl-listing.c
+++ b/trunk/src/auditctl-listing.c
@@ -63,7 +63,8 @@ int key_match(const struct audit_rule_data *r)
}
if (((field >= AUDIT_SUBJ_USER && field <= AUDIT_OBJ_LEV_HIGH)
&& field != AUDIT_PPID) || field == AUDIT_WATCH ||
- field == AUDIT_DIR || field == AUDIT_FILTERKEY) {
+ field == AUDIT_DIR || field == AUDIT_FILTERKEY
+ || field == AUDIT_EXE || field == AUDIT_EXE_CHILDREN) {
boffset += r->values[i];
}
}
@@ -347,6 +348,11 @@ static void print_rule(const struct audit_rule_data *r)
&r->buf[boffset]);
boffset += r->values[i];
+ } else if (field == AUDIT_EXE || field == AUDIT_EXE_CHILDREN) {
+ printf(" -F exe%s=%.*s",
+ field == AUDIT_EXE_CHILDREN ? "_children" : "",
+ r->values[i], &r->buf[boffset]);
+ boffset += r->values[i];
} else if (field == AUDIT_FILTERKEY) {
char *rkey, *ptr;
if (asprintf(&rkey, "%.*s", r->values[i],
--
1.7.1
10 years, 6 months
Using the audit-libs-python in Python 3.3
by Исаев Виталий Анатольевич
Hello,
I encountered difficulties when I tried to use the auparse module in Python 3.3. I would like to use this module with a modern version of the interpreter due to severe memory leaks in my auparse-based script that is run in Python 2.6.6 (which is default for RHEL 6.4). The problem is described here: http://stackoverflow.com/questions/23369937/python-memory-consumption-on-.... Surely it can be my own fault (cyclic links preventing the gc work or something else), but some people from Stackoverflow community advised me to use Python 3+ since it works with dynamic memory more properly. I would like to do it first.
So I tried to import auparse module from the audit-libs-python into the interpreter that was distributed with the latest version of LibreOffice:
[root@vitaly registration]# yum info audit-libs-python
Loaded plugins: product-id, refresh-packagekit, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Installed Packages
Name : audit-libs-python
Arch : x86_64
Version : 2.2
Release : 2.el6
Size : 267 k
Repo : installed
>From repo : repository-204
Summary : Python bindings for libaudit
URL : http://people.redhat.com/sgrubb/audit/
License : LGPLv2+
Description : The audit-libs-python package contains the bindings so that libaudit
: and libauparse can be used by python.
[root@vitaly registration]# rpm -q --provides audit-libs-python
_audit.so()(64bit)
auparse.so()(64bit)
audit-libs-python = 2.2-2.el6
audit-libs-python(x86-64) = 2.2-2.el6
[vitaly@vitaly registration]$ /opt/libreoffice4.2/program/python
Python 3.3.3 (default, Jan 28 2014, 10:45:06)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append('/usr/lib64/python2.6/site-packages/')
>>> from auparse import AuParser
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: /usr/lib64/python2.6/site-packages/auparse.so: undefined symbol: _Py_ZeroStruct
>>>
I will appreciate if someone could help me to import this module to Python 3.3. Thank you a lot!
Vitaly Isaev
Software engineer
Information security department
Fintech JSC, Moscow, Russia
10 years, 6 months
Re: [RFC][PATCH] selinux: Report result in avc messages
by Eric Paris
On Tue, 2014-04-29 at 16:54 -0700, Stephen Smalley wrote:
> Requested for Android in order to distinguish denials that are not in
> fact breaking anything yet due to permissive domains versus denials
> that are being enforced, but seems generally useful. result field was
> already in the selinux audit data structure and was being passed to
> avc_audit() but wasn't being used. Seems to cause no harm to ausearch
> or audit2allow to add it as a field. Comments?
I think it's a great idea, but I'm worried that Steve is going to get
grumpy because an AVC record is going to have a result= field which is
similar, but not necessarily related to the res= field of a SYSCALL
record. Seems easily confused (although probably 9999 times out of
10000 they will be the same)
So while I wholeheartedly think we should take the idea, I wonder if
someone can dream up a name that isn't confusingly similar...
I can't think of anything...
-Eric
10 years, 6 months
[PATCH] Support for auditing on the actions of a not-yet-executed process.
by Peter Moody
eg:
-a exit,always -F arch=b64 -S socket -F 'a0!=1' -F exe=/bin/bash -F success=1
to see instances of /bin/bash opening a non-local socket. Or
-a exit,always -F arch=b64 -S socket -F 'a0!=1' -F exe_children=/bin/bash -F success=1
to instances of /bin/bash, and any descendant processes, opening a non local socket.
proposed https://www.redhat.com/archives/linux-audit/2012-June/msg00002.html
and it seemed like there was interest.
Signed-off-by: Peter Moody <pmoody(a)google.com>
---
trunk/lib/errormsg.h | 2 +-
trunk/lib/fieldtab.h | 2 ++
trunk/lib/libaudit.c | 11 +++++++++++
trunk/lib/libaudit.h | 7 ++++++-
4 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/trunk/lib/errormsg.h b/trunk/lib/errormsg.h
index 4d996d5..cd595ec 100644
--- a/trunk/lib/errormsg.h
+++ b/trunk/lib/errormsg.h
@@ -51,7 +51,7 @@ static const struct msg_tab err_msgtab[] = {
{ -15, 2, "-F unknown errno -"},
{ -16, 2, "-F unknown file type - " },
{ -17, 1, "can only be used with exit and entry filter list" },
- { -18, 1, "" }, // Unused
+ { -18, 1, "only takes = operator" },
{ -19, 0, "Key field needs a watch or syscall given prior to it" },
{ -20, 2, "-F missing value after operation for" },
{ -21, 2, "-F value should be number for" },
diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h
index c0432cc..245b541 100644
--- a/trunk/lib/fieldtab.h
+++ b/trunk/lib/fieldtab.h
@@ -66,3 +66,5 @@ _S(AUDIT_ARG3, "a3" )
_S(AUDIT_FILTERKEY, "key" )
_S(AUDIT_FIELD_COMPARE, "field_compare" )
+_S(AUDIT_EXE, "exe" )
+_S(AUDIT_EXE_CHILDREN, "exe_children" )
diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c
index 20eaf5f..06eed86 100644
--- a/trunk/lib/libaudit.c
+++ b/trunk/lib/libaudit.c
@@ -1400,6 +1400,17 @@ int audit_rule_fieldpair_data(struct audit_rule_data **rulep, const char *pair,
else
return -21;
break;
+ case AUDIT_EXE_CHILDREN:
+ case AUDIT_EXE:
+ {
+ struct stat buf;
+ if ((stat(v, &buf)) < 0)
+ return -2;
+ if (op != AUDIT_EQUAL)
+ return -18;
+ rule->values[rule->field_count] = (unsigned long)buf.st_ino;
+ }
+ break;
case AUDIT_DEVMAJOR...AUDIT_INODE:
case AUDIT_SUCCESS:
if (flags != AUDIT_FILTER_EXIT)
diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h
index 89dd588..2c8a802 100644
--- a/trunk/lib/libaudit.h
+++ b/trunk/lib/libaudit.h
@@ -243,6 +243,12 @@ extern "C" {
#ifndef AUDIT_FIELD_COMPARE
#define AUDIT_FIELD_COMPARE 111
#endif
+#ifndef AUDIT_EXE
+#define AUDIT_EXE 112
+#endif
+#ifndef AUDIT_EXE_CHILDREN
+#define AUDIT_EXE_CHILDREN 113
+#endif
#ifndef AUDIT_COMPARE_UID_TO_OBJ_UID
#define AUDIT_COMPARE_UID_TO_OBJ_UID 1
@@ -524,4 +530,3 @@ extern void audit_rule_free_data(struct audit_rule_data *rule);
#endif
#endif
-
--
1.7.7.3
10 years, 6 months
