[PATCH v2] audit: remove useless code in audit_enable

[Gao feng]

Since kernel parameter is operated before
initcall, so the audit_initialized must be
AUDIT_UNINITIALIZED or DISABLED in audit_enable.

Signed-off-by: Gao feng 
---
 kernel/audit.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

change from v1:
convert "printk(KERN_INFO " to "pr_info(".
thanks Richard for pointing out.

diff --git a/kernel/audit.c b/kernel/audit.c
index 8378c5e..7c7c028 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1038,17 +1038,8 @@ static int __init audit_enable(char *str)
if (!audit_default)
audit_initialized = AUDIT_DISABLED;
 
-   printk(KERN_INFO "audit: %s", audit_default ? "enabled" : "disabled");
-
-   if (audit_initialized == AUDIT_INITIALIZED) {
-   audit_enabled = audit_default;
-   audit_ever_enabled |= !!audit_default;
-   } else if (audit_initialized == AUDIT_UNINITIALIZED) {
-   printk(" (after initialization)");
-   } else {
-   printk(" (until reboot)");
-   }
-   printk("\n");
+   pr_info("audit: %s\n", audit_default ?
+   "enabled (after initialization)" : "disabled (until reboot)");
 
return 1;
 }
-- 
1.8.3.1

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] audit: Add cmdline to taskinfo output

[William Roberts]

On Wed, Oct 30, 2013 at 2:20 PM, Eric Paris  wrote:

> I'm like a child wandering into the middle of a movie and having no idea
> what is going on.  But...
>

my day to day reality :-P


>
> > The limit is PATH_MAX. You could have an absolute path that
> > uses all available
> > characters.
> >
> > -Steve
> >
> >
> > So looking at PATH_MAX...
> > include/linux/limits.h:12:#define PATH_MAX4096 /* # chars in a
> > path name including nul */
>
> I seem to recall that PATH_MAX is not really PATH_MAX  :)  It can be +10
> ish...   for the " (deleted)" that gets appended if things are
> unlinked...  just something I sorta recall rolling around the back of my
> head and I haven't really any idea if it is applicable here in any
> way...
>
>
I don't think so. The concern is PAGE_SIZE is to big for a message, so lets
pick something else
to truncate the message size on, the suggesting was PATH_MAX which makes
sense
and works in this case.

The patch I have on top of what I submitted so far is to pick PAGE_SIZE or
PATH_MAX, whichever is
smaller.

-- 
Respectfully,

William C Roberts
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] audit: Add cmdline to taskinfo output

[Eric Paris]

I'm like a child wandering into the middle of a movie and having no idea
what is going on.  But...

> The limit is PATH_MAX. You could have an absolute path that
> uses all available
> characters.
> 
> -Steve
> 
> 
> So looking at PATH_MAX...
> include/linux/limits.h:12:#define PATH_MAX4096 /* # chars in a
> path name including nul */

I seem to recall that PATH_MAX is not really PATH_MAX  :)  It can be +10
ish...   for the " (deleted)" that gets appended if things are
unlinked...  just something I sorta recall rolling around the back of my
head and I haven't really any idea if it is applicable here in any
way...


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

[PATCH 3/3] audit: call audit_bprm() only once to add AUDIT_EXECVE information

[Richard Guy Briggs]

Move the audit_bprm() call from search_binary_handler() to exec_binprm().  This
allows us to get rid of the mm member of struct audit_aux_data_execve since
bprm->mm will equal current->mm.

This also mitigates the issue that ->argc could be modified by the
load_binary() call in search_binary_handler().

audit_bprm() was being called to add an AUDIT_EXECVE record to the audit
context every time search_binary_handler() was recursively called.  Only one
reference is necessary.  Merge the remaining argc parameter into the union in
audit_context, removing a kmalloc.

Reported-by: Oleg Nesterov 
Cc: Eric Paris 
Signed-off-by: Richard Guy Briggs 
---
 fs/exec.c |5 +
 include/linux/audit.h |   13 +
 kernel/audit.h|3 +++
 kernel/auditsc.c  |   41 ++---
 4 files changed, 19 insertions(+), 43 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 8875dd1..47d7edb 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1385,10 +1385,6 @@ int search_binary_handler(struct linux_binprm *bprm)
if (retval)
return retval;
 
-   retval = audit_bprm(bprm);
-   if (retval)
-   return retval;
-
retval = -ENOENT;
  retry:
read_lock(&binfmt_lock);
@@ -1436,6 +1432,7 @@ static int exec_binprm(struct linux_binprm *bprm)
 
ret = search_binary_handler(bprm);
if (ret >= 0) {
+   audit_bprm(bprm);
trace_sched_process_exec(current, old_pid, bprm);
ptrace_event(PTRACE_EVENT_EXEC, old_vpid);
current->did_exec = 1;
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 729a4d1..a757e6c 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -207,7 +207,7 @@ static inline int audit_get_sessionid(struct task_struct 
*tsk)
 
 extern void __audit_ipc_obj(struct kern_ipc_perm *ipcp);
 extern void __audit_ipc_set_perm(unsigned long qbytes, uid_t uid, gid_t gid, 
umode_t mode);
-extern int __audit_bprm(struct linux_binprm *bprm);
+extern void __audit_bprm(struct linux_binprm *bprm);
 extern int __audit_socketcall(int nargs, unsigned long *args);
 extern int __audit_sockaddr(int len, void *addr);
 extern void __audit_fd_pair(int fd1, int fd2);
@@ -236,11 +236,10 @@ static inline void audit_ipc_set_perm(unsigned long 
qbytes, uid_t uid, gid_t gid
if (unlikely(!audit_dummy_context()))
__audit_ipc_set_perm(qbytes, uid, gid, mode);
 }
-static inline int audit_bprm(struct linux_binprm *bprm)
+static inline void audit_bprm(struct linux_binprm *bprm)
 {
if (unlikely(!audit_dummy_context()))
-   return __audit_bprm(bprm);
-   return 0;
+   __audit_bprm(bprm);
 }
 static inline int audit_socketcall(int nargs, unsigned long *args)
 {
@@ -367,10 +366,8 @@ static inline void audit_ipc_obj(struct kern_ipc_perm 
*ipcp)
 static inline void audit_ipc_set_perm(unsigned long qbytes, uid_t uid,
gid_t gid, umode_t mode)
 { }
-static inline int audit_bprm(struct linux_binprm *bprm)
-{
-   return 0;
-}
+static inline void audit_bprm(struct linux_binprm *bprm)
+{ }
 static inline int audit_socketcall(int nargs, unsigned long *args)
 {
return 0;
diff --git a/kernel/audit.h b/kernel/audit.h
index 123c9b7..b779642 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -197,6 +197,9 @@ struct audit_context {
int fd;
int flags;
} mmap;
+   struct {
+   int argc;
+   } execve;
};
int fds[2];
 
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index c9abaa0..dc1adee 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -95,12 +95,6 @@ struct audit_aux_data {
 /* Number of target pids per aux struct. */
 #define AUDIT_AUX_PIDS 16
 
-struct audit_aux_data_execve {
-   struct audit_aux_data   d;
-   int argc;
-   struct mm_struct *mm;
-};
-
 struct audit_aux_data_pids {
struct audit_aux_data   d;
pid_t   target_pid[AUDIT_AUX_PIDS];
@@ -1144,20 +1138,16 @@ static int audit_log_single_execve_arg(struct 
audit_context *context,
 }
 
 static void audit_log_execve_info(struct audit_context *context,
- struct audit_buffer **ab,
- struct audit_aux_data_execve *axi)
+ struct audit_buffer **ab)
 {
int i, len;
size_t len_sent = 0;
const char __user *p;
char *buf;
 
-   if (axi->mm != current->mm)
-   return; /* execve failed, no additional info */
-
-   p = (const char __user *)axi->mm->arg_start;
+   p = (const char __user *)current->mm->arg_start;
 
-   audit_log_format(*ab, "argc=%d", axi->argc);
+   audit_log_format(*ab, "argc=%d", context->execve.argc);
 
/*
   

[PATCH 0/3] audit: Tidy up audit_context and stop bprm recursion

[Richard Guy Briggs]

This patchset is a clean up of the audit_aux_data and audit_context structures
and the audit_bprm() call that was needlessly recursing, allocating more
resources than necessary.

Eric W. Biederman (1):
  audit: Kill the unused struct audit_aux_data_capset

Richard Guy Briggs (2):
  audit: remove unused envc member of audit_aux_data_execve
  audit: call audit_bprm() only once to add AUDIT_EXECVE information

 fs/exec.c |5 +
 include/linux/audit.h |   13 +
 kernel/audit.h|3 +++
 kernel/auditsc.c  |   49 ++---
 4 files changed, 19 insertions(+), 51 deletions(-)

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

[PATCH 2/3] audit: remove unused envc member of audit_aux_data_execve

[Richard Guy Briggs]

Get rid of write-only audit_aux_data_exeve structure member envc.

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 24047f4..c9abaa0 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -98,7 +98,6 @@ struct audit_aux_data {
 struct audit_aux_data_execve {
struct audit_aux_data   d;
int argc;
-   int envc;
struct mm_struct *mm;
 };
 
@@ -2132,7 +2131,6 @@ int __audit_bprm(struct linux_binprm *bprm)
return -ENOMEM;
 
ax->argc = bprm->argc;
-   ax->envc = bprm->envc;
ax->mm = bprm->mm;
ax->d.type = AUDIT_EXECVE;
ax->d.next = context->aux;
-- 
1.7.1

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

[PATCH 1/3] audit: Kill the unused struct audit_aux_data_capset

[Richard Guy Briggs]

From: Eric W. Biederman 

Signed-off-by: "Eric W. Biederman" 
(cherry picked from commit 6904431d6b41190e42d6b94430b67cb4e7e6a4b7)
(cherry picked from commit 2b3a6c617396a9e6eedae9a56b2d9642da0216b6)
---
 kernel/auditsc.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 95293ab..24047f4 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -121,12 +121,6 @@ struct audit_aux_data_bprm_fcaps {
struct audit_cap_data   new_pcap;
 };
 
-struct audit_aux_data_capset {
-   struct audit_aux_data   d;
-   pid_t   pid;
-   struct audit_cap_data   cap;
-};
-
 struct audit_tree_refs {
struct audit_tree_refs *next;
struct audit_chunk *c[31];
-- 
1.7.1

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH] audit: Add cmdline to taskinfo output

[William Roberts]

On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb  wrote:

> On Tuesday, October 29, 2013 05:43:36 PM William Roberts wrote:
> > >> I guess I could just set the comm field explicitly via the packagename
> > >> when the classloader loads the value, but I was hoping for something
> more
> > >> generic that would
> > >> let me get larger package names then 16.
> > >
> > > I made the change of setting the comm field from within the VM, but its
> > > less then ideal... that 16char limitation is a pain. In Android Java
> Land,
> > > some of the packages that get run can be quite large. Also, current
> APIs
> > > in Javaland already change this...
> > >
> > > Also, a more generic solution would be desired.
> > >
> > > Lets look at what happens:
> > > type=SYSCALL msg=audit(10/29/2013 15:16:08.185:177) : arch=unknown elf
> > > type(4028) syscall=fstat per=84 success=yes exit=38 a0=7432ed34
> > > a1=20241 a2=180 a3=7432ed0c items=1 ppid=322 pid=1432 auid=unset
> > > uid=unknown(1027) gid=unknown(1027) euid=unknown(1027)
> suid=unknown(1027)
> > > fsuid=unknown(1027) egid=unknown(1027) sgid=unknown(1027)
> > > fsgid=unknown(1027) tty=(none) ses=4294967295 comm=AsyncTask #1
> > > exe=/system/bin/app_process cmdline="com.android.nfc" subj=u:r:nfc:s0
> > > key=(null)
> > >
> > > Here the nfc task has an async task, that async task api sets the cmd
> > > field when it attaches a thread to the VM
> > >
> > > type=1300 msg=audit(1383088554.170:322): arch=4028 syscall=54
> > > per=84 success=yes exit=0 a0=a a1=c0186201 a2=be985430 a3=be98542c
> > > items=0 ppid=321 pid=1181 auid=4294967295 uid=10036 gid=10036
> euid=10036
> > > suid=10036 fsuid=10036 egid=10036 sgid=10036 fsgid=10036 tty=(none)
> > > ses=4294967295 comm="putmethod.latin" exe="/system/bin/app_process"
> > > cmdline="com.android.inputmethod.latin" subj=u:r:shared_app:s0
> key=(null)
> > >
> > > Again... the comm field got cut off and now I have no idea again.
>
> Which is the same as all arches. What I'm trying to say is that all arches
> would benefit from fixing this problem. I don't like the idea of it
> getting fixed
> for one platform and leaving it for all others to figure out another day.
>

By arches your don't mean arm right? This code runs the same on other
architectures. If
you mean platforms, like Android, vs some other Linux distro, then yes I
want a generic
approach, which I think cmdline gets us... no mater how many layers of VM
exec/forking
indirection hell you may find yourself in, you at least get a chance at
what started the chain.
On Android, that happens to be the packagename.


>
> Is there some reason that the length of that field must be set to 16? I've
> seen
> user id numbers increased by a config option. It might be that the naming
> convention of android apps is enough to get a change.
>
> > I think exe= in the audit logs is essentially arg[0]... so thats not
> going
> > to work here,
>

We can't change the naming convention of andorid apps, too large of an
ecosystem to
change and no real easy way to be backwards compatible. That one is off the
table.

I have compiled kernels in the past with custom COMM widths, but the memory
footprint
goes up, at least here were not keeping a bunch of possibly unused data
around in the kernel
plus we're not allocating anything on the common case of it being turned
off.


> The original problem was shell scripts. We got /bin/bash and had no idea
> what
> was being executed. So, cmd was offered as a quick fix.
>
> > and I don't think I can change that value from userspace as its not
> > > logged with untrusted string, which is a good indication its mutable
> from
> > > userspace.
> > >
> > > Why dont I just limit the size of what is displayed on cmdline to
> > > something like 128 or 256?
> > >
> > > Eventually some limit has to be set, whether its PAGE_SIZE or
> not..their
> > > will always be an argument of "too much memory". But its also
> important to
> > > note its off by default, you have to turn it on, so most desktop
> instances
> > > will leave it off, whilst I will dynamically enable it as needed.
> > >
> > > Thanks again for your review and help, I appreciate it.
> >
> > Looking further into your size concerns, EXECVE is truncated at 7500
> >
> > kernel/auditsc.c:
> > #define MAX_EXECVE_AUDIT_LEN 7500
>
> I think that is for the purposes of splitting records. At the time,
> compiling
> a kernel or maybe linking it allowed passing thousands of file names on the
> command line and Eric wrote a patch to split the execve record into
> multiple
> ones. Userspace had to be adapted to glue them back together.
>

Ahh ok, thanks.


>
> > the proc cmdline info is truncated at PAGE_SIZE, which most of the time
> in
> > 4096.. so its even smaller then that.
>
> And then if there is a space in the path, it gets encoded so double that
> size.
>

Ahh yeah.. forgot about those.


>
> > So based on our discussion, whats the next step at moving forward on
> this?
> >
> > Do you want a sep

Re: [PATCH] audit: Add cmdline to taskinfo output

[Steve Grubb]

On Tuesday, October 29, 2013 05:43:36 PM William Roberts wrote:
> >> I guess I could just set the comm field explicitly via the packagename
> >> when the classloader loads the value, but I was hoping for something more
> >> generic that would
> >> let me get larger package names then 16.
> > 
> > I made the change of setting the comm field from within the VM, but its
> > less then ideal... that 16char limitation is a pain. In Android Java Land,
> > some of the packages that get run can be quite large. Also, current APIs
> > in Javaland already change this...
> > 
> > Also, a more generic solution would be desired.
> > 
> > Lets look at what happens:
> > type=SYSCALL msg=audit(10/29/2013 15:16:08.185:177) : arch=unknown elf
> > type(4028) syscall=fstat per=84 success=yes exit=38 a0=7432ed34
> > a1=20241 a2=180 a3=7432ed0c items=1 ppid=322 pid=1432 auid=unset
> > uid=unknown(1027) gid=unknown(1027) euid=unknown(1027) suid=unknown(1027)
> > fsuid=unknown(1027) egid=unknown(1027) sgid=unknown(1027)
> > fsgid=unknown(1027) tty=(none) ses=4294967295 comm=AsyncTask #1
> > exe=/system/bin/app_process cmdline="com.android.nfc" subj=u:r:nfc:s0
> > key=(null)
> > 
> > Here the nfc task has an async task, that async task api sets the cmd
> > field when it attaches a thread to the VM
> > 
> > type=1300 msg=audit(1383088554.170:322): arch=4028 syscall=54
> > per=84 success=yes exit=0 a0=a a1=c0186201 a2=be985430 a3=be98542c
> > items=0 ppid=321 pid=1181 auid=4294967295 uid=10036 gid=10036 euid=10036
> > suid=10036 fsuid=10036 egid=10036 sgid=10036 fsgid=10036 tty=(none)
> > ses=4294967295 comm="putmethod.latin" exe="/system/bin/app_process"
> > cmdline="com.android.inputmethod.latin" subj=u:r:shared_app:s0 key=(null)
> > 
> > Again... the comm field got cut off and now I have no idea again.

Which is the same as all arches. What I'm trying to say is that all arches 
would benefit from fixing this problem. I don't like the idea of it getting 
fixed 
for one platform and leaving it for all others to figure out another day.

Is there some reason that the length of that field must be set to 16? I've seen 
user id numbers increased by a config option. It might be that the naming 
convention of android apps is enough to get a change.

> I think exe= in the audit logs is essentially arg[0]... so thats not going
> to work here, 

The original problem was shell scripts. We got /bin/bash and had no idea what 
was being executed. So, cmd was offered as a quick fix.

> and I don't think I can change that value from userspace as its not
> > logged with untrusted string, which is a good indication its mutable from
> > userspace.
> > 
> > Why dont I just limit the size of what is displayed on cmdline to
> > something like 128 or 256?
> > 
> > Eventually some limit has to be set, whether its PAGE_SIZE or not..their
> > will always be an argument of "too much memory". But its also important to
> > note its off by default, you have to turn it on, so most desktop instances
> > will leave it off, whilst I will dynamically enable it as needed.
> > 
> > Thanks again for your review and help, I appreciate it.
> 
> Looking further into your size concerns, EXECVE is truncated at 7500
> 
> kernel/auditsc.c:
> #define MAX_EXECVE_AUDIT_LEN 7500

I think that is for the purposes of splitting records. At the time, compiling 
a kernel or maybe linking it allowed passing thousands of file names on the 
command line and Eric wrote a patch to split the execve record into multiple 
ones. Userspace had to be adapted to glue them back together.
 
> the proc cmdline info is truncated at PAGE_SIZE, which most of the time in
> 4096.. so its even smaller then that.

And then if there is a space in the path, it gets encoded so double that size.

> So based on our discussion, whats the next step at moving forward on this?
> 
> Do you want a separate limit other then PAGE_SIZE on this?

The limit is PATH_MAX. You could have an absolute path that uses all available 
characters.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: ABIs, syscall tables, and the AUDIT_ARCH_* defines

[Paul Moore]

On Tuesday, October 29, 2013 05:29:41 PM Eric Paris wrote:
> On Tue, 2013-10-29 at 17:28 -0400, Paul Moore wrote:
> > Take x86_64 and x32 as an example (think of x32 as a 32-bit version of
> > x86_64).  Both x32 and x86_64 use the AUDIT_ARCH_X86_64 value and general
> > calling convention, but they have a different syscall table.
> 
> I guess a good question is "is that right" ?
> 
> #define AUDIT_ARCH_X86_64 (EM_X86_64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> 
> Would we not be better off with a:
> 
> #define AUDIT_ARCH_X32 (EM_X86_64|__AUDIT_ARCH_LE)   ?

If you look at the libseccomp code, that is exactly how we define 
SCMP_ARCH_X32.  To me it makes sense.

However, I think it may already be too late to change things in the kernel.  
Support for x32 has been in mainline for a while now and userspace has already 
had to deal with it; changing to AUDIT_ARCH_X32, while arguably The Right 
Thing To Do, would likely involve userspace breakage.  At least it would break 
libseccomp :)

> Do x86_64 and x32 share the same syscall entry code?

I can't say off the top of my head, but if I had to guess, I would say yes.

UPDATE: I took a quick peek and while I'm not well versed on the syscall entry 
code, it does appear that they share most of the important bits.

> Is there where the AUDIT_ARCH_X86_64 comes from?

I believe so.  Depending on the state of CONFIG_AUDITSYSCALL it either gets 
passed directly as the first argument to __audit_syscall_entry() in entry_64.S 
or via syscall_trace_enter() which once again just uses AUDIT_ARCH_X86_64.

In both cases it should be possible to set it to a new AUDIT_ARCH_X32, but my 
previous concerns about userspace breakage still apply.

> Is this similar for ARM?  Right now, the only thing we have is:
> 
> #define AUDIT_ARCH_ARM  (EM_ARM|__AUDIT_ARCH_LE)
> #define AUDIT_ARCH_ARMEB(EM_ARM)
> 
> Is this enough?  Should we add more?

No idea really, I'm still getting up to speed on ARM.  Personally, ARM OABI is 
really weird and considering that most everything is EABI now, I don't think 
I'm ever going to support ARM OABI in libseccomp.

The answer might not be as easy for audit since the kernel technically already 
supports ARM OABI, but I'm guessing that if you haven't head anyone shouting 
at you by now you might not have to worry too much about it.

> I'm way way way more ARM idiotic than I am about x86_64.

Me too.  Although the more I learn about ARM the more it scares me.

> I know the ARM people at least told us that ARM wasn't going to work right
> with what we have today...  So they added to the audit Kconfig:
> 
> depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 ||
> SUPERH || (ARM && AEABI && !OABI_COMPAT))

Hmm, so that might be your "out" here, unless you really want to deal with ARM 
OABI :)  I'm not even entirely sure if OABI works on the newer ARM hardware.

> Is fixing this with differentiated AUDIT_ARCH flags even possible?  Am I
> just talking out of my bum?

/me shrugs

Sorry, still learning this stuff too.

-- 
paul moore
security and virtualization @ redhat

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

ABIs, syscall tables, and the AUDIT_ARCH_* defines

[Paul Moore]

Hello all,

I've been dealing with the AUDIT_ARCH_* defines, different ABIs and syscall 
tables a fair amount lately as part of libseccomp[1] and a little birdie 
thought it might be a good idea to post something to the Linux audit list.

So here we go.  I'll try to be brief.

First off, if you already understand that in some cases a given AUDIT_ARCH_* 
value can represent multiple ABIs and you are fine with that, feel free to hit 
delete now and move on.  I'm not trying to argue that what audit is currently 
doing is right or wrong, just trying to make things perhaps a bit more clear.

The core issue is that AUDIT_ARCH alone can not be used to specify a given 
ABI, all the AUDIT_ARCH value can tell you is the syscall table; which in it's 
defense, is all the original source comments claim.  However, if you want to 
be able to identify an ABI, I'm finding that you need both the AUDIT_ARCH 
value and the syscall number (from my experience this hold true for x86, 
x86_64, x32, ARM OABI, and ARM EABI, I can't speak for others at this point).  

Take x86_64 and x32 as an example (think of x32 as a 32-bit version of 
x86_64).  Both x32 and x86_64 use the AUDIT_ARCH_X86_64 value and general 
calling convention, but they have a different syscall table.  The x32 syscall 
table is the same as the x86_64 syscall table but with a 0x4000 offset, 
e.g. on x86_64 the write() syscall is 0x01 but on x32 write() is 0x4001.  
The 32-bit ARM ABIs are similar in that the EABI and OABI ABIs share the same 
AUDIT_ARCH_ARM value and have similar syscall tables, separated by a 0x90 
offset.  With ARM there is some additional oddities between OABI and EABI with 
respect to syscall arguments, but I'm still figuring that out myself and it 
wouldn't be right for me to talk about that here.

There ya go, hopefully this helps somewhat.  If you have any questions I'll do 
my best to try and answer them.

-Paul

[1] http://sourceforge.net/projects/libseccomp

-- 
paul moore
security and virtualization @ redhat

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

UNSUBSCRIBE

[Wilson, Mark - IS]

UNSUBSCRIBE





This e-mail and any files transmitted with it may be proprietary and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this e-mail in error please notify the sender. 
Please note that any views or opinions presented in this e-mail are solely 
those of the author and do not necessarily represent those of Exelis Inc. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. Exelis Inc. accepts no liability for any damage caused by any virus 
transmitted by this e-mail.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit