* [PATCH 5/5] Fix header detection when cross compiling
From: Clayton Shotwell @ 2015-05-28 13:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1432818249-17692-1-git-send-email-clayton.shotwell@rockwellcollins.com>
During the build, there is a check to see if MS_DIRSYNC is defined in
mount.h. This check is used in gen_tables.c to see if linux/fs.h needs
to be included. When cross compiling on a system that does not have the
MS_DIRSYNC defined in mount.h, a compile failure is generated. To
prevent this issue, do not check for MS_DIRSYNC in the configure and
simply check to see if MS_DIRSYNC is defined before included linux/fs.h.
Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
---
configure.ac | 1 -
lib/gen_tables.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c14ec80..e63684b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -63,7 +63,6 @@ AC_C_INLINE
AC_CHECK_SIZEOF([unsigned int])
AC_CHECK_SIZEOF([unsigned long])
AM_PROG_CC_C_O
-AC_CHECK_DECLS([MS_DIRSYNC], [], [], [[#include <sys/mount.h>]])
AC_CHECK_DECLS([AUDIT_FEATURE_VERSION], [], [], [[#include <linux/audit.h>]])
AC_CHECK_DECLS([AUDIT_VERSION_BACKLOG_WAIT_TIME], [], [], [[#include <linux/audit.h>]])
AC_CHECK_DECLS([ADDR_NO_RANDOMIZE],,, [#include <sys/personality.h>])
diff --git a/lib/gen_tables.c b/lib/gen_tables.c
index 8606a39..9f25b50 100644
--- a/lib/gen_tables.c
+++ b/lib/gen_tables.c
@@ -33,7 +33,7 @@
#include <sys/stat.h>
#include <sys/personality.h>
#include <sys/mount.h>
-#if !HAVE_DECL_MS_DIRSYNC
+#ifndef MS_DIRSYNC
#include <linux/fs.h>
#endif
#include "gen_tables.h"
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] Default ADDR_NO_RANDOMIZE if not found
From: Clayton Shotwell @ 2015-05-28 13:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1432818249-17692-1-git-send-email-clayton.shotwell@rockwellcollins.com>
Some older toolchains do not declare ADDR_NO_RANDOMIZE. Add a check for
it during configure and default it if it is not found.
Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
---
auparse/interpret.c | 4 ++++
configure.ac | 1 +
2 files changed, 5 insertions(+)
diff --git a/auparse/interpret.c b/auparse/interpret.c
index 0dcaa9f..a9d6691 100644
--- a/auparse/interpret.c
+++ b/auparse/interpret.c
@@ -53,6 +53,10 @@
#include "auparse-defs.h"
#include "gen_tables.h"
+#if !HAVE_DECL_ADDR_NO_RANDOMIZE
+# define ADDR_NO_RANDOMIZE 0x0040000
+#endif
+
/* This is from asm/ipc.h. Copying it for now as some platforms
* have broken headers. */
#define SEMOP 1
diff --git a/configure.ac b/configure.ac
index 2e84b07..57aec03 100644
--- a/configure.ac
+++ b/configure.ac
@@ -66,6 +66,7 @@ AM_PROG_CC_C_O
AC_CHECK_DECLS([MS_DIRSYNC], [], [], [[#include <sys/mount.h>]])
AC_CHECK_DECLS([AUDIT_FEATURE_VERSION], [], [], [[#include <linux/audit.h>]])
AC_CHECK_DECLS([AUDIT_VERSION_BACKLOG_WAIT_TIME], [], [], [[#include <linux/audit.h>]])
+AC_CHECK_DECLS([ADDR_NO_RANDOMIZE],,, [#include <sys/personality.h>])
ALLWARNS=""
ALLDEBUG="-g"
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] Enable cross compiling
From: Clayton Shotwell @ 2015-05-28 13:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1432818249-17692-1-git-send-email-clayton.shotwell@rockwellcollins.com>
During the audit build, several lookup tables are generated as header
files that are then linked in with the executables. This process is done
by a C application that needs to be able to be run on the host. The
current Makfile structure tries to build these executables for the
target instead of the host where they cannot be executed. This patch
reworks the Makefile structure to build for the correct platform.
This patch is a rework of a patch posted to the audit mailing list at
the link below.
https://www.redhat.com/archives/linux-audit/2012-November/msg00000.html
The ax_prog_cc_for_build.m4 file was obtained from GNU at the link
below.
http://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
---
auparse/Makefile.am | 276 ++++++++++++++++++++++++++++++---------------
configure.ac | 1 +
lib/Makefile.am | 133 ++++++++++++++--------
m4/ax_prog_cc_for_build.m4 | 125 ++++++++++++++++++++
4 files changed, 397 insertions(+), 138 deletions(-)
create mode 100644 m4/ax_prog_cc_for_build.m4
diff --git a/auparse/Makefile.am b/auparse/Makefile.am
index 89b2d21..0fe40e0 100644
--- a/auparse/Makefile.am
+++ b/auparse/Makefile.am
@@ -57,208 +57,304 @@ BUILT_SOURCES = accesstabs.h captabs.h clocktabs.h clone-flagtabs.h \
seektabs.h shm_modetabs.h signaltabs.h sockoptnametabs.h \
socktabs.h sockleveltabs.h socktypetabs.h \
tcpoptnametabs.h typetabs.h umounttabs.h
-noinst_PROGRAMS = gen_accesstabs_h gen_captabs_h gen_clock_h \
- gen_clone-flagtabs_h \
- gen_epoll_ctls_h gen_famtabs_h \
- gen_fcntl-cmdtabs_h gen_flagtabs_h gen_ioctlreqtabs_h \
- gen_icmptypetabs_h gen_ipctabs_h gen_ipccmdtabs_h\
- gen_ipoptnametabs_h gen_ip6optnametabs_h gen_nfprototabs_h \
- gen_mmaptabs_h gen_mounttabs_h \
- gen_open-flagtabs_h gen_persontabs_h \
- gen_prctl_opttabs_h gen_pktoptnametabs_h gen_prottabs_h \
- gen_recvtabs_h gen_rlimit_h gen_ptracetabs_h \
- gen_schedtabs_h gen_seccomptabs_h \
- gen_seektabs_h gen_shm_modetabs_h gen_signals_h \
- gen_sockoptnametabs_h gen_socktabs_h gen_sockleveltabs_h \
- gen_socktypetabs_h gen_tcpoptnametabs_h gen_typetabs_h \
- gen_umounttabs_h
-
-gen_accesstabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h accesstab.h
-gen_accesstabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="accesstab.h"'
+
+gen_accesstabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h accesstab.h
+gen_accesstabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="accesstab.h"'
+gen_accesstabs_h: $(gen_accesstabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_accesstabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
accesstabs.h: gen_accesstabs_h Makefile
./gen_accesstabs_h --i2s-transtab access > $@
-gen_captabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h captab.h
-gen_captabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="captab.h"'
+gen_captabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h captab.h
+gen_captabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="captab.h"'
+gen_captabs_h: $(gen_captabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_captabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
captabs.h: gen_captabs_h Makefile
./gen_captabs_h --i2s cap > $@
-gen_clock_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h clocktab.h
-gen_clock_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="clocktab.h"'
+gen_clock_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h clocktab.h
+gen_clock_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="clocktab.h"'
+gen_clock_h: $(gen_clock_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_clock_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
clocktabs.h: gen_clock_h Makefile
./gen_clock_h --i2s clock > $@
-gen_clone_flagtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h \
+gen_clone_flagtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h \
clone-flagtab.h
-gen_clone_flagtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="clone-flagtab.h"'
+gen_clone_flagtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="clone-flagtab.h"'
+gen_clone-flagtabs_h: $(gen_clone_flagtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_clone_flagtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
clone-flagtabs.h: gen_clone-flagtabs_h Makefile
./gen_clone-flagtabs_h --i2s-transtab clone_flag > $@
-gen_epoll_ctls_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h epoll_ctl.h
-gen_epoll_ctls_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="epoll_ctl.h"'
+gen_epoll_ctls_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h epoll_ctl.h
+gen_epoll_ctls_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="epoll_ctl.h"'
+gen_epoll_ctls_h: $(gen_epoll_ctls_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_epoll_ctls_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
epoll_ctls.h: gen_epoll_ctls_h Makefile
./gen_epoll_ctls_h --i2s epoll_ctl > $@
-gen_famtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h famtab.h
-gen_famtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="famtab.h"'
+gen_famtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h famtab.h
+gen_famtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="famtab.h"'
+gen_famtabs_h: $(gen_famtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_famtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
famtabs.h: gen_famtabs_h Makefile
./gen_famtabs_h --i2s fam > $@
-gen_flagtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h flagtab.h
+gen_flagtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h flagtab.h
# ../auparse/ is used to avoid using ../lib/flagtab.h
-gen_flagtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="../auparse/flagtab.h"'
+gen_flagtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="../auparse/flagtab.h"'
+gen_flagtabs_h: $(gen_flagtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_flagtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
flagtabs.h: gen_flagtabs_h Makefile
./gen_flagtabs_h --i2s-transtab flag > $@
-gen_fcntl_cmdtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h \
+gen_fcntl_cmdtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h \
fcntl-cmdtab.h
-gen_fcntl_cmdtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="fcntl-cmdtab.h"'
+gen_fcntl_cmdtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="fcntl-cmdtab.h"'
+gen_fcntl-cmdtabs_h: $(gen_fcntl_cmdtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_fcntl_cmdtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
fcntl-cmdtabs.h: gen_fcntl-cmdtabs_h Makefile
./gen_fcntl-cmdtabs_h --i2s fcntl > $@
-gen_icmptypetabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h icmptypetab.h
-gen_icmptypetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="icmptypetab.h"'
+gen_icmptypetabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h icmptypetab.h
+gen_icmptypetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="icmptypetab.h"'
+gen_icmptypetabs_h: $(gen_icmptypetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_icmptypetabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
icmptypetabs.h: gen_icmptypetabs_h Makefile
./gen_icmptypetabs_h --i2s icmptype > $@
-gen_ioctlreqtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ioctlreqtab.h
-gen_ioctlreqtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ioctlreqtab.h"'
+gen_ioctlreqtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ioctlreqtab.h
+gen_ioctlreqtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ioctlreqtab.h"'
+gen_ioctlreqtabs_h: $(gen_ioctlreqtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ioctlreqtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
ioctlreqtabs.h: gen_ioctlreqtabs_h Makefile
./gen_ioctlreqtabs_h --i2s ioctlreq > $@
-gen_ipctabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ipctab.h
-gen_ipctabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ipctab.h"'
+gen_ipctabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ipctab.h
+gen_ipctabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ipctab.h"'
+gen_ipctabs_h: $(gen_ipctabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ipctabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
ipctabs.h: gen_ipctabs_h Makefile
./gen_ipctabs_h --i2s ipc > $@
-gen_ipccmdtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ipccmdtab.h
-gen_ipccmdtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ipccmdtab.h"'
+gen_ipccmdtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ipccmdtab.h
+gen_ipccmdtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ipccmdtab.h"'
+gen_ipccmdtabs_h: $(gen_ipccmdtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ipccmdtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
ipccmdtabs.h: gen_ipccmdtabs_h Makefile
./gen_ipccmdtabs_h --i2s-transtab ipccmd > $@
-gen_ipoptnametabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ipoptnametab.h
-gen_ipoptnametabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ipoptnametab.h"'
+gen_ipoptnametabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ipoptnametab.h
+gen_ipoptnametabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ipoptnametab.h"'
+gen_ipoptnametabs_h: $(gen_ipoptnametabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ipoptnametabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
ipoptnametabs.h: gen_ipoptnametabs_h Makefile
./gen_ipoptnametabs_h --i2s ipoptname > $@
-gen_ip6optnametabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ip6optnametab.h
-gen_ip6optnametabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ip6optnametab.h"'
+gen_ip6optnametabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ip6optnametab.h
+gen_ip6optnametabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ip6optnametab.h"'
+gen_ip6optnametabs_h: $(gen_ip6optnametabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ip6optnametabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
ip6optnametabs.h: gen_ip6optnametabs_h Makefile
./gen_ip6optnametabs_h --i2s ip6optname > $@
-gen_mmaptabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h mmaptab.h
-gen_mmaptabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="mmaptab.h"'
+gen_mmaptabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h mmaptab.h
+gen_mmaptabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="mmaptab.h"'
+gen_mmaptabs_h: $(gen_mmaptabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_mmaptabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
mmaptabs.h: gen_mmaptabs_h Makefile
./gen_mmaptabs_h --i2s-transtab mmap > $@
-gen_mounttabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h mounttab.h
-gen_mounttabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="mounttab.h"'
+gen_mounttabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h mounttab.h
+gen_mounttabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="mounttab.h"'
+gen_mounttabs_h: $(gen_mounttabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_mounttabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
mounttabs.h: gen_mounttabs_h Makefile
./gen_mounttabs_h --i2s-transtab mount > $@
-gen_nfprototabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h nfprototab.h
-gen_nfprototabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="nfprototab.h"'
+gen_nfprototabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h nfprototab.h
+gen_nfprototabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="nfprototab.h"'
+gen_nfprototabs_h: $(gen_nfprototabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_nfprototabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
nfprototabs.h: gen_nfprototabs_h Makefile
./gen_nfprototabs_h --i2s nfproto > $@
-gen_open_flagtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h \
+gen_open_flagtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h \
open-flagtab.h
-gen_open_flagtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="open-flagtab.h"'
+gen_open_flagtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="open-flagtab.h"'
+gen_open-flagtabs_h: $(gen_open_flagtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_open_flagtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
open-flagtabs.h: gen_open-flagtabs_h Makefile
./gen_open-flagtabs_h --i2s-transtab open_flag > $@
-gen_persontabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h persontab.h
-gen_persontabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="persontab.h"'
+gen_persontabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h persontab.h
+gen_persontabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="persontab.h"'
+gen_persontabs_h: $(gen_persontabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_persontabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
persontabs.h: gen_persontabs_h Makefile
./gen_persontabs_h --i2s person > $@
-gen_ptracetabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ptracetab.h
-gen_ptracetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ptracetab.h"'
+gen_ptracetabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h ptracetab.h
+gen_ptracetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ptracetab.h"'
+gen_ptracetabs_h: $(gen_ptracetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ptracetabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
ptracetabs.h: gen_ptracetabs_h Makefile
./gen_ptracetabs_h --i2s ptrace > $@
-gen_prctl_opttabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h prctl-opt-tab.h
-gen_prctl_opttabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="prctl-opt-tab.h"'
+gen_prctl_opttabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h prctl-opt-tab.h
+gen_prctl_opttabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="prctl-opt-tab.h"'
+gen_prctl_opttabs_h: $(gen_prctl_opttabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_prctl_opttabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
prctl_opttabs.h: gen_prctl_opttabs_h Makefile
./gen_prctl_opttabs_h --i2s prctl_opt > $@
-gen_pktoptnametabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h pktoptnametab.h
-gen_pktoptnametabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="pktoptnametab.h"'
+gen_pktoptnametabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h pktoptnametab.h
+gen_pktoptnametabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="pktoptnametab.h"'
+gen_pktoptnametabs_h: $(gen_pktoptnametabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_pktoptnametabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
pktoptnametabs.h: gen_pktoptnametabs_h Makefile
./gen_pktoptnametabs_h --i2s pktoptname > $@
-gen_prottabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h prottab.h
-gen_prottabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="prottab.h"'
+gen_prottabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h prottab.h
+gen_prottabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="prottab.h"'
+gen_prottabs_h: $(gen_prottabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_prottabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
prottabs.h: gen_prottabs_h Makefile
./gen_prottabs_h --i2s-transtab prot > $@
-gen_recvtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h recvtab.h
-gen_recvtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="recvtab.h"'
+gen_recvtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h recvtab.h
+gen_recvtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="recvtab.h"'
+gen_recvtabs_h: $(gen_recvtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_recvtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
recvtabs.h: gen_recvtabs_h Makefile
./gen_recvtabs_h --i2s-transtab recv > $@
-gen_rlimit_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h rlimittab.h
-gen_rlimit_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="rlimittab.h"'
+gen_rlimit_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h rlimittab.h
+gen_rlimit_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="rlimittab.h"'
+gen_rlimit_h: $(gen_rlimit_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_rlimit_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
rlimittabs.h: gen_rlimit_h Makefile
./gen_rlimit_h --i2s rlimit > $@
-gen_schedtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h schedtab.h
-gen_schedtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="schedtab.h"'
+gen_schedtabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h schedtab.h
+gen_schedtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="schedtab.h"'
+gen_schedtabs_h: $(gen_schedtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_schedtabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
schedtabs.h: gen_schedtabs_h Makefile
./gen_schedtabs_h --i2s sched > $@
-gen_seccomptabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h seccomptab.h
-gen_seccomptabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="seccomptab.h"'
+gen_seccomptabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h seccomptab.h
+gen_seccomptabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="seccomptab.h"'
+gen_seccomptabs_h: $(gen_seccomptabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_seccomptabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
seccomptabs.h: gen_seccomptabs_h Makefile
./gen_seccomptabs_h --i2s seccomp > $@
-gen_seektabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h seektab.h
-gen_seektabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="seektab.h"'
+gen_seektabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h seektab.h
+gen_seektabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="seektab.h"'
+gen_seektabs_h: $(gen_seektabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_seektabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
seektabs.h: gen_seektabs_h Makefile
./gen_seektabs_h --i2s seek > $@
-gen_shm_modetabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h shm_modetab.h
-gen_shm_modetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="shm_modetab.h"'
+gen_shm_modetabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h shm_modetab.h
+gen_shm_modetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="shm_modetab.h"'
+gen_shm_modetabs_h: $(gen_shm_modetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_shm_modetabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
shm_modetabs.h: gen_shm_modetabs_h Makefile
./gen_shm_modetabs_h --i2s-transtab shm_mode > $@
-gen_signals_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h signaltab.h
-gen_signals_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="signaltab.h"'
+gen_signals_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h signaltab.h
+gen_signals_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="signaltab.h"'
+gen_signals_h: $(gen_signals_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_signals_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
signaltabs.h: gen_signals_h Makefile
./gen_signals_h --i2s signal > $@
-gen_sockleveltabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h sockleveltab.h
-gen_sockleveltabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="sockleveltab.h"'
+gen_sockleveltabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h sockleveltab.h
+gen_sockleveltabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="sockleveltab.h"'
+gen_sockleveltabs_h: $(gen_sockleveltabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_sockleveltabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
sockleveltabs.h: gen_sockleveltabs_h Makefile
./gen_sockleveltabs_h --i2s socklevel > $@
-gen_sockoptnametabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h sockoptnametab.h
-gen_sockoptnametabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="sockoptnametab.h"'
+gen_sockoptnametabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h sockoptnametab.h
+gen_sockoptnametabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="sockoptnametab.h"'
+gen_sockoptnametabs_h: $(gen_sockoptnametabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_sockoptnametabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
sockoptnametabs.h: gen_sockoptnametabs_h Makefile
./gen_sockoptnametabs_h --i2s sockoptname > $@
-gen_socktabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h socktab.h
-gen_socktabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="socktab.h"'
+gen_socktabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h socktab.h
+gen_socktabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="socktab.h"'
+gen_socktabs_h: $(gen_socktabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_socktabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
socktabs.h: gen_socktabs_h Makefile
./gen_socktabs_h --i2s sock > $@
-gen_socktypetabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h socktypetab.h
-gen_socktypetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="socktypetab.h"'
+gen_socktypetabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h socktypetab.h
+gen_socktypetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="socktypetab.h"'
+gen_socktypetabs_h: $(gen_socktypetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_socktypetabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
socktypetabs.h: gen_socktypetabs_h Makefile
./gen_socktypetabs_h --i2s sock_type > $@
-gen_tcpoptnametabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h tcpoptnametab.h
-gen_tcpoptnametabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="tcpoptnametab.h"'
+gen_tcpoptnametabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h tcpoptnametab.h
+gen_tcpoptnametabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="tcpoptnametab.h"'
+gen_tcpoptnametabs_h: $(gen_tcpoptnametabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_tcpoptnametabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
tcpoptnametabs.h: gen_tcpoptnametabs_h Makefile
./gen_tcpoptnametabs_h --i2s tcpoptname > $@
-gen_typetabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h typetab.h
-gen_typetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="typetab.h"'
+gen_typetabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h typetab.h
+gen_typetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="typetab.h"'
+gen_typetabs_h: $(gen_typetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_typetabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
typetabs.h: gen_typetabs_h Makefile
./gen_typetabs_h --s2i type > $@
-gen_umounttabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h umounttab.h
-gen_umounttabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="umounttab.h"'
+gen_umounttabs_h_BUILDSOURCES = ../lib/gen_tables.c ../lib/gen_tables.h umounttab.h
+gen_umounttabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="umounttab.h"'
+gen_umounttabs_h: $(gen_umounttabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_umounttabs_h_BUILDCFLAGS) \
+ -o $@ ../lib/gen_tables.c
umounttabs.h: gen_umounttabs_h Makefile
./gen_umounttabs_h --i2s-transtab umount > $@
diff --git a/configure.ac b/configure.ac
index ad9084b..f29fa41 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,6 +51,7 @@ echo Checking for programs
AC_PROG_CC
AC_PROG_INSTALL
AC_PROG_AWK
+AX_PROG_CC_FOR_BUILD
echo .
echo Checking for header files
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 3560a88..1e5ec9f 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -55,109 +55,146 @@ endif
if USE_AARCH64
BUILT_SOURCES += aarch64_tables.h
endif
-noinst_PROGRAMS = gen_actiontabs_h gen_errtabs_h gen_fieldtabs_h \
- gen_flagtabs_h gen_ftypetabs_h gen_i386_tables_h \
- gen_ia64_tables_h gen_machinetabs_h gen_msg_typetabs_h \
- gen_optabs_h gen_ppc_tables_h gen_s390_tables_h \
- gen_s390x_tables_h gen_x86_64_tables_h
-if USE_ALPHA
-noinst_PROGRAMS += gen_alpha_tables_h
-endif
-if USE_ARM
-noinst_PROGRAMS += gen_arm_tables_h
-endif
-if USE_AARCH64
-noinst_PROGRAMS += gen_aarch64_tables_h
-endif
-gen_actiontabs_h_SOURCES = gen_tables.c gen_tables.h actiontab.h
-gen_actiontabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="actiontab.h"'
+gen_actiontabs_h_BUILDSOURCES = gen_tables.c gen_tables.h actiontab.h
+gen_actiontabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="actiontab.h"'
+gen_actiontabs_h: $(gen_actiontabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_actiontabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
actiontabs.h: gen_actiontabs_h Makefile
./gen_actiontabs_h --lowercase --i2s --s2i action > $@
if USE_ALPHA
-gen_alpha_tables_h_SOURCES = gen_tables.c gen_tables.h alpha_table.h
-gen_alpha_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="alpha_table.h"'
+gen_alpha_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h alpha_table.h
+gen_alpha_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="alpha_table.h"'
+gen_alpha_tables_h : $(gen_alpha_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_alpha_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
alpha_tables.h: gen_alpha_tables_h Makefile
./gen_alpha_tables_h --lowercase --i2s --s2i alpha_syscall > $@
endif
if USE_ARM
-gen_arm_tables_h_SOURCES = gen_tables.c gen_tables.h arm_table.h
-gen_arm_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="arm_table.h"'
+gen_arm_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h arm_table.h
+gen_arm_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="arm_table.h"'
+gen_arm_tables_h : $(gen_arm_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_arm_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
arm_tables.h: gen_arm_tables_h Makefile
./gen_arm_tables_h --lowercase --i2s --s2i arm_syscall > $@
endif
if USE_AARCH64
-gen_aarch64_tables_h_SOURCES = gen_tables.c gen_tables.h aarch64_table.h
-gen_aarch64_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="aarch64_table.h"'
+gen_aarch64_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h aarch64_table.h
+gen_aarch64_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="aarch64_table.h"'
+gen_aarch64_tables_h : $(gen_aarch64_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_aarch64_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
aarch64_tables.h: gen_aarch64_tables_h Makefile
./gen_aarch64_tables_h --lowercase --i2s --s2i aarch64_syscall > $@
endif
-gen_errtabs_h_SOURCES = gen_tables.c gen_tables.h errtab.h
-gen_errtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="errtab.h"'
+gen_errtabs_h_BUILDSOURCES = gen_tables.c gen_tables.h errtab.h
+gen_errtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="errtab.h"'
+gen_errtabs_h : $(gen_errtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_errtabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
errtabs.h: gen_errtabs_h Makefile
./gen_errtabs_h --duplicate-ints --uppercase --i2s --s2i err > $@
-gen_fieldtabs_h_SOURCES = gen_tables.c gen_tables.h fieldtab.h
-gen_fieldtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="fieldtab.h"'
+gen_fieldtabs_h_BUILDSOURCES = gen_tables.c gen_tables.h fieldtab.h
+gen_fieldtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="fieldtab.h"'
+gen_fieldtabs_h : $(gen_fieldtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_fieldtabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
fieldtabs.h: gen_fieldtabs_h Makefile
./gen_fieldtabs_h --duplicate-ints --lowercase --i2s --s2i field > $@
-gen_flagtabs_h_SOURCES = gen_tables.c gen_tables.h flagtab.h
-gen_flagtabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="flagtab.h"'
+gen_flagtabs_h_BUILDSOURCES = gen_tables.c gen_tables.h flagtab.h
+gen_flagtabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="flagtab.h"'
+gen_flagtabs_h : $(gen_flagtabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_flagtabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
flagtabs.h: gen_flagtabs_h Makefile
./gen_flagtabs_h --lowercase --i2s --s2i flag > $@
-gen_ftypetabs_h_SOURCES = gen_tables.c gen_tables.h ftypetab.h
-gen_ftypetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ftypetab.h"'
+gen_ftypetabs_h_BUILDSOURCES = gen_tables.c gen_tables.h ftypetab.h
+gen_ftypetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ftypetab.h"'
+gen_ftypetabs_h : $(gen_ftypetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ftypetabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
ftypetabs.h: gen_ftypetabs_h Makefile
./gen_ftypetabs_h --lowercase --i2s --s2i ftype > $@
-gen_i386_tables_h_SOURCES = gen_tables.c gen_tables.h i386_table.h
-gen_i386_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="i386_table.h"'
+gen_i386_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h i386_table.h
+gen_i386_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="i386_table.h"'
+gen_i386_tables_h : $(gen_i386_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_i386_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
i386_tables.h: gen_i386_tables_h Makefile
./gen_i386_tables_h --duplicate-ints --lowercase --i2s --s2i \
i386_syscall > $@
-gen_ia64_tables_h_SOURCES = gen_tables.c gen_tables.h ia64_table.h
-gen_ia64_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ia64_table.h"'
+gen_ia64_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h ia64_table.h
+gen_ia64_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ia64_table.h"'
+gen_ia64_tables_h : $(gen_ia64_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ia64_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
ia64_tables.h: gen_ia64_tables_h Makefile
./gen_ia64_tables_h --lowercase --i2s --s2i ia64_syscall > $@
-gen_machinetabs_h_SOURCES = gen_tables.c gen_tables.h machinetab.h
-gen_machinetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="machinetab.h"'
+gen_machinetabs_h_BUILDSOURCES = gen_tables.c gen_tables.h machinetab.h
+gen_machinetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="machinetab.h"'
+gen_machinetabs_h : $(gen_machinetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_machinetabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
machinetabs.h: gen_machinetabs_h Makefile
./gen_machinetabs_h --duplicate-ints --lowercase --i2s --s2i machine \
> $@
-gen_msg_typetabs_h_SOURCES = gen_tables.c gen_tables.h msg_typetab.h
-gen_msg_typetabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="msg_typetab.h"'
+gen_msg_typetabs_h_BUILDSOURCES = gen_tables.c gen_tables.h msg_typetab.h
+gen_msg_typetabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="msg_typetab.h"'
+gen_msg_typetabs_h : $(gen_msg_typetabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_msg_typetabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
msg_typetabs.h: gen_msg_typetabs_h Makefile
./gen_msg_typetabs_h --uppercase --i2s --s2i msg_type > $@
-gen_optabs_h_SOURCES = gen_tables.c gen_tables.h optab.h
-gen_optabs_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="optab.h"'
+gen_optabs_h_BUILDSOURCES = gen_tables.c gen_tables.h optab.h
+gen_optabs_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="optab.h"'
+gen_optabs_h : $(gen_optabs_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_optabs_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
optabs.h: gen_optabs_h Makefile
./gen_optabs_h --i2s op > $@
-gen_ppc_tables_h_SOURCES = gen_tables.c gen_tables.h ppc_table.h
-gen_ppc_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="ppc_table.h"'
+gen_ppc_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h ppc_table.h
+gen_ppc_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="ppc_table.h"'
+gen_ppc_tables_h : $(gen_ppc_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_ppc_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
ppc_tables.h: gen_ppc_tables_h Makefile
./gen_ppc_tables_h --lowercase --i2s --s2i ppc_syscall > $@
-gen_s390_tables_h_SOURCES = gen_tables.c gen_tables.h s390_table.h
-gen_s390_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="s390_table.h"'
+gen_s390_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h s390_table.h
+gen_s390_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="s390_table.h"'
+gen_s390_tables_h : $(gen_s390_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_s390_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
s390_tables.h: gen_s390_tables_h Makefile
./gen_s390_tables_h --lowercase --i2s --s2i s390_syscall > $@
-gen_s390x_tables_h_SOURCES = gen_tables.c gen_tables.h s390x_table.h
-gen_s390x_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="s390x_table.h"'
+gen_s390x_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h s390x_table.h
+gen_s390x_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="s390x_table.h"'
+gen_s390x_tables_h : $(gen_s390x_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_s390x_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
s390x_tables.h: gen_s390x_tables_h Makefile
./gen_s390x_tables_h --lowercase --i2s --s2i s390x_syscall > $@
-gen_x86_64_tables_h_SOURCES = gen_tables.c gen_tables.h x86_64_table.h
-gen_x86_64_tables_h_CFLAGS = $(AM_CFLAGS) '-DTABLE_H="x86_64_table.h"'
+gen_x86_64_tables_h_BUILDSOURCES = gen_tables.c gen_tables.h x86_64_table.h
+gen_x86_64_tables_h_BUILDCFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H="x86_64_table.h"'
+gen_x86_64_tables_h : $(gen_x86_64_tables_h_BUILDSOURCES)
+ $(CC_FOR_BUILD) $(INCLUDES) $(gen_x86_64_tables_h_BUILDCFLAGS) \
+ -o $@ gen_tables.c
x86_64_tables.h: gen_x86_64_tables_h Makefile
./gen_x86_64_tables_h --lowercase --i2s --s2i x86_64_syscall > $@
diff --git a/m4/ax_prog_cc_for_build.m4 b/m4/ax_prog_cc_for_build.m4
new file mode 100644
index 0000000..77fd346
--- /dev/null
+++ b/m4/ax_prog_cc_for_build.m4
@@ -0,0 +1,125 @@
+# ===========================================================================
+# http://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+# ===========================================================================
+#
+# SYNOPSIS
+#
+# AX_PROG_CC_FOR_BUILD
+#
+# DESCRIPTION
+#
+# This macro searches for a C compiler that generates native executables,
+# that is a C compiler that surely is not a cross-compiler. This can be
+# useful if you have to generate source code at compile-time like for
+# example GCC does.
+#
+# The macro sets the CC_FOR_BUILD and CPP_FOR_BUILD macros to anything
+# needed to compile or link (CC_FOR_BUILD) and preprocess (CPP_FOR_BUILD).
+# The value of these variables can be overridden by the user by specifying
+# a compiler with an environment variable (like you do for standard CC).
+#
+# It also sets BUILD_EXEEXT and BUILD_OBJEXT to the executable and object
+# file extensions for the build platform, and GCC_FOR_BUILD to `yes' if
+# the compiler we found is GCC. All these variables but GCC_FOR_BUILD are
+# substituted in the Makefile.
+#
+# LICENSE
+#
+# Copyright (c) 2008 Paolo Bonzini <bonzini@gnu.org>
+#
+# Copying and distribution of this file, with or without modification, are
+# permitted in any medium without royalty provided the copyright notice
+# and this notice are preserved. This file is offered as-is, without any
+# warranty.
+
+#serial 8
+
+AU_ALIAS([AC_PROG_CC_FOR_BUILD], [AX_PROG_CC_FOR_BUILD])
+AC_DEFUN([AX_PROG_CC_FOR_BUILD], [dnl
+AC_REQUIRE([AC_PROG_CC])dnl
+AC_REQUIRE([AC_PROG_CPP])dnl
+AC_REQUIRE([AC_EXEEXT])dnl
+AC_REQUIRE([AC_CANONICAL_HOST])dnl
+
+dnl Use the standard macros, but make them use other variable names
+dnl
+pushdef([ac_cv_prog_CPP], ac_cv_build_prog_CPP)dnl
+pushdef([ac_cv_prog_gcc], ac_cv_build_prog_gcc)dnl
+pushdef([ac_cv_prog_cc_works], ac_cv_build_prog_cc_works)dnl
+pushdef([ac_cv_prog_cc_cross], ac_cv_build_prog_cc_cross)dnl
+pushdef([ac_cv_prog_cc_g], ac_cv_build_prog_cc_g)dnl
+pushdef([ac_cv_exeext], ac_cv_build_exeext)dnl
+pushdef([ac_cv_objext], ac_cv_build_objext)dnl
+pushdef([ac_exeext], ac_build_exeext)dnl
+pushdef([ac_objext], ac_build_objext)dnl
+pushdef([CC], CC_FOR_BUILD)dnl
+pushdef([CPP], CPP_FOR_BUILD)dnl
+pushdef([CFLAGS], CFLAGS_FOR_BUILD)dnl
+pushdef([CPPFLAGS], CPPFLAGS_FOR_BUILD)dnl
+pushdef([LDFLAGS], LDFLAGS_FOR_BUILD)dnl
+pushdef([host], build)dnl
+pushdef([host_alias], build_alias)dnl
+pushdef([host_cpu], build_cpu)dnl
+pushdef([host_vendor], build_vendor)dnl
+pushdef([host_os], build_os)dnl
+pushdef([ac_cv_host], ac_cv_build)dnl
+pushdef([ac_cv_host_alias], ac_cv_build_alias)dnl
+pushdef([ac_cv_host_cpu], ac_cv_build_cpu)dnl
+pushdef([ac_cv_host_vendor], ac_cv_build_vendor)dnl
+pushdef([ac_cv_host_os], ac_cv_build_os)dnl
+pushdef([ac_cpp], ac_build_cpp)dnl
+pushdef([ac_compile], ac_build_compile)dnl
+pushdef([ac_link], ac_build_link)dnl
+
+save_cross_compiling=$cross_compiling
+save_ac_tool_prefix=$ac_tool_prefix
+cross_compiling=no
+ac_tool_prefix=
+
+AC_PROG_CC
+AC_PROG_CPP
+AC_EXEEXT
+
+ac_tool_prefix=$save_ac_tool_prefix
+cross_compiling=$save_cross_compiling
+
+dnl Restore the old definitions
+dnl
+popdef([ac_link])dnl
+popdef([ac_compile])dnl
+popdef([ac_cpp])dnl
+popdef([ac_cv_host_os])dnl
+popdef([ac_cv_host_vendor])dnl
+popdef([ac_cv_host_cpu])dnl
+popdef([ac_cv_host_alias])dnl
+popdef([ac_cv_host])dnl
+popdef([host_os])dnl
+popdef([host_vendor])dnl
+popdef([host_cpu])dnl
+popdef([host_alias])dnl
+popdef([host])dnl
+popdef([LDFLAGS])dnl
+popdef([CPPFLAGS])dnl
+popdef([CFLAGS])dnl
+popdef([CPP])dnl
+popdef([CC])dnl
+popdef([ac_objext])dnl
+popdef([ac_exeext])dnl
+popdef([ac_cv_objext])dnl
+popdef([ac_cv_exeext])dnl
+popdef([ac_cv_prog_cc_g])dnl
+popdef([ac_cv_prog_cc_cross])dnl
+popdef([ac_cv_prog_cc_works])dnl
+popdef([ac_cv_prog_gcc])dnl
+popdef([ac_cv_prog_CPP])dnl
+
+dnl Finally, set Makefile variables
+dnl
+BUILD_EXEEXT=$ac_build_exeext
+BUILD_OBJEXT=$ac_build_objext
+AC_SUBST(BUILD_EXEEXT)dnl
+AC_SUBST(BUILD_OBJEXT)dnl
+AC_SUBST([CFLAGS_FOR_BUILD])dnl
+AC_SUBST([CPPFLAGS_FOR_BUILD])dnl
+AC_SUBST([LDFLAGS_FOR_BUILD])dnl
+])
--
1.9.1
^ permalink raw reply related
* [PATCH 0/5] Audit Cross Compile Fixes
From: Clayton Shotwell @ 2015-05-28 13:04 UTC (permalink / raw)
To: linux-audit
The following are 5 patches that I have been working on for a while to
allow the audit package to cross compile correctly for various targets.
This work is all being done to add audit along with SELinux to the
Buildroot build system. Most of the changes are minor and only relate
to compile time issues with toolchains, such as uClibc, and missing
dependencies. See the link below for the Buildroot patch submission.
http://buildroot-busybox.2317881.n4.nabble.com/PATCH-v6-00-22-SELinux-Buildroot-Additions-td102124.html
The one major patch enables cross compiling support for the gen_tables.c
functionality. Since gen_tables needs to be run on the host rather than
the target, I had to add Automake support for handling the host compiler.
I based these changes off of a patch set done a couple of years ago (See
link below), a similar patch set I and done, while incorporating the
feedback received from the community.
https://www.redhat.com/archives/linux-audit/2012-November/msg00000.html
Any feedback would be greatly appreciated.
Clayton Shotwell (5):
Enable cross compiling
Make zos-remote plugin optional
Default ADDR_NO_RANDOMIZE if not found
Do not call posix_fallocate() if unavailable
Fix header detection when cross compiling
audisp/plugins/Makefile.am | 6 +-
audisp/plugins/remote/queue.c | 2 +
auparse/Makefile.am | 276 ++++++++++++++++++++++++++++--------------
auparse/interpret.c | 4 +
configure.ac | 14 ++-
lib/Makefile.am | 133 ++++++++++++--------
lib/gen_tables.c | 2 +-
m4/ax_prog_cc_for_build.m4 | 125 +++++++++++++++++++
8 files changed, 420 insertions(+), 142 deletions(-)
create mode 100644 m4/ax_prog_cc_for_build.m4
--
1.9.1
^ permalink raw reply
* [PATCH 4/5] Do not call posix_fallocate() if unavailable
From: Clayton Shotwell @ 2015-05-28 13:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1432818249-17692-1-git-send-email-clayton.shotwell@rockwellcollins.com>
uClibc does not implement posix_fallocate(), and posix_fallocate() is
mostly only an hint to the kernel that we will need such or such
amount of space inside a file. Adding a check around the
posix_fallocate() call so it is only called when it is available.
Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
---
audisp/plugins/remote/queue.c | 2 ++
configure.ac | 1 +
2 files changed, 3 insertions(+)
diff --git a/audisp/plugins/remote/queue.c b/audisp/plugins/remote/queue.c
index 79eebd7..971e4e4 100644
--- a/audisp/plugins/remote/queue.c
+++ b/audisp/plugins/remote/queue.c
@@ -215,9 +215,11 @@ static int q_open_file(struct queue *q, const char *path)
return -1;
if (q_sync(q) != 0)
return -1;
+#ifdef HAVE_POSIX_FALLOCATE
if (posix_fallocate(q->fd, 0,
(q->num_entries + 1) * q->entry_size) != 0)
return -1;
+#endif
} else {
uint32_t file_entries;
if (full_pread(q->fd, &fh, sizeof(fh), 0) != 0)
diff --git a/configure.ac b/configure.ac
index 57aec03..c14ec80 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,7 @@ AC_CHECK_DECLS([MS_DIRSYNC], [], [], [[#include <sys/mount.h>]])
AC_CHECK_DECLS([AUDIT_FEATURE_VERSION], [], [], [[#include <linux/audit.h>]])
AC_CHECK_DECLS([AUDIT_VERSION_BACKLOG_WAIT_TIME], [], [], [[#include <linux/audit.h>]])
AC_CHECK_DECLS([ADDR_NO_RANDOMIZE],,, [#include <sys/personality.h>])
+AC_CHECK_FUNCS([posix_fallocate])
ALLWARNS=""
ALLDEBUG="-g"
--
1.9.1
^ permalink raw reply related
* Re: log rendering in real time in audit-viewer
From: Arthym Krivo @ 2015-05-27 15:26 UTC (permalink / raw)
To: mitr; +Cc: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 182 bytes --]
Hello,
I applied this patch [1] and it works well.
Don't understand why he stayed without attention?
-A.K.
[1] https://www.redhat.com/archives/linux-audit/2015-March/msg00018.html
[-- Attachment #1.2: Type: text/html, Size: 445 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH 1/1] Obsolete check is now removed.
From: Mikhail Klementyev @ 2015-05-27 13:41 UTC (permalink / raw)
To: linux-audit; +Cc: rgb
[-- Attachment #1.1: Type: text/plain, Size: 1796 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- From a2e33ce7c9b5ceff2a8b570b570ddd0023ce077f Mon Sep 17 00:00:00 2001
From: Mikhail Klementyev<jollheef@riseup.net>
Date: Mon, 25 May 2015 23:20:38 +0300
Subject: [PATCH 1/1] Obsolete check is now removed.
Signed-off-by: Mikhail Klementyev<jollheef@riseup.net>
- ---
kernel/auditsc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9fb9d1c..ee09794 100644
- --- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -599,9 +599,7 @@ static int audit_filter_rules(struct task_struct *tsk,
result = match_tree_refs(ctx, rule->tree);
break;
case AUDIT_LOGINUID:
- - result = 0;
- - if (ctx)
- - result = audit_uid_comparator(tsk->loginuid, f->op, f->uid);
+ result = audit_uid_comparator(tsk->loginuid, f->op, f->uid);
break;
case AUDIT_LOGINUID_SET:
result = audit_comparator(audit_loginuid_set(tsk), f->op, f->val);
- --
2.0.5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVY4cJAAoJEE7XYCHzWN5TQVkQAMYCSkzSlIVA9sTmrZk0bDA1
62pbY22hEFfWN41268hjhhQ/wiuM14LI34oTeCPnqxQIopTt9bnAW9ZwPfgNFG2F
T/nSLZVJMwjjs/b1DrAV4fDWYtlIjedm/HhhumFIyOfDkAPIgs2cBcWiGkB6D9ly
oi/ccMaTo4c59kfTwCjYKgpY8iPMdm547fR8YVEt+eX+nfJSMbCcrnkBoFoZl4tk
RHjKmuTyjJ9U5ht94Rws/xKMYQ+g+I+CV6L1FpzOY9ZVaFLelsOJKiipkXMemwih
NCC4qtd6HF/rbd0jFQpzU1QViw7y/ZxcduAmqmr7yg1oxNYqhzt9OIcKlH1QWqrQ
eKdPDxd23n+t9yri1cIExb0Cik6ySRR0lRn/IOfSAgaJAZX0r5+Db+LkWYymXgHp
D8edl1WvpjkNo+R/GjNvaDM9jKB3Z6FblUlteqMQB9mCnwys3YKcc4ma5aGXbO24
fF28r632nDZrj+knIU171VtEyEjbnzo05bJnIiOW167STKBmbFgHgGTI/yhCHBro
wp6kg0ns+WK3tE+BvXhG/iysTAUvAhf/bnMlFaZ8j1GGhEzWGJveDINEIcCzRsoR
UncA/96yN4Sqw1Acq5+s9SaD+NMt++Iz1JbYck8rpJlO8zgpxF/6lb9Fz1B9o/LH
B20jap46V3UDEjzEp3DS
=Puu1
-----END PGP SIGNATURE-----
[-- Attachment #1.2: Type: text/html, Size: 2307 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Excluding files from auditing
From: Xavier Lashmar @ 2015-05-26 19:41 UTC (permalink / raw)
To: linux-audit@redhat.com
Hi there,
I've configured audit.rules on a server that I administer, to log all file-system activity matching permissions "wa". A few files under these directories are to be excluded. In particular, I am attempting to exclude the logging of actions on files which may not yet exist.
For example:
A user like "Apache" might try to read and write to a file called "thisfileexists.php" which exists on the FS. I consider this action perfectly valid and do not require it to be logged; instead I create a rule to exclude it, using the system call matching rule "exit,never -F path=..."
On the other hand, a user like "Apache" might try to write to a file called "thisfilesdoesnotyetexist.php" which does not yet exist, which I also consider to be a perfectly valid action, and require no log of. This action however, is on a specific file that I know Apache will try to write to, but has not yet been created and may never exist.
An example configuration of /etc/audit/audit.rules
#### EXCLUDE FALSE POSITIVES ####
-a exit,never -F path=/var/www/html/somepath/thisfilesdoesnotexist.php
-a exit,never -F path=/var/www/html/somepath/thisfileexists.php
#### LOG EVERYTHING ELSE ####
-w /var/www/html -p wa -k webserver-writes
Essentially the above rule should log all activity, except for the excluded items:
/var/www/html/somepath/thisfilesdoesnotexist.php
/var/www/html/somepath/thisfileexists.php
However, since "thisfiledoesnotexist.php" does not actually exist, it seems that the audit rule does not apply and if the "Apache" user tries to create it, the action gets logged. This is not what I want or expected.
The "thisfileexists.php" on the other hand, does exist and the audit rule seem to function and does NOT log write actions. This is what I want and expected.
>From the above experiment I deduce that an audit rule to exclude from logging a system-call using "exit,never", will not function if the file it refers to does not exist. Is this correct or did I simply make a mistake?
Thank you for any clarification provided,
Xavier Lashmar
Analyste de Systèmes | Systems Analyst
Service étudiants | Student Web Services
Service de l'informatique et des communications | Computing and Communications Services.
Tél. | Tel. 613-562-5800 (2120)
^ permalink raw reply
* Re: auditd and SSHD exported variables
From: Burn Alting @ 2015-05-26 11:46 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1542043.cVvLZ5qY0x@x2>
Steve,
I am assuming that Guillaume has a situation where he wants to provide a
unique sshd key as a login token as opposed to a user account name token
we find in /etc/passwd (or it's equivalent). In practice, it should just
require a single level of indirection. That is map the sshd key to the
account name and then to the account's uid in some corporate repository.
Regards
On Mon, 2015-05-25 at 18:09 -0400, Steve Grubb wrote:
> On Monday, May 25, 2015 09:37:33 AM Guillaume L. wrote:
> > Hello,
> >
> > Thank you for your response.
> >
> > I hoped that there are another ways to do this :)
> >
> > I will explore pam to try to create a module !
>
> The audit system in its entirety is designed with the assumption that each
> user has their own account. Its for this reason that all security guidance
> asks that root logins be disallowed. (Root is typically a shared account and
> you cannot tell who did what if root logins were allowed.)
>
> I'm not sure of the use case. Perhaps it really doesn't matter to have an
> audit trail. But without any knowledge of the problem that one common account
> solves, I say that you might consider giving people different accounts and use
> supplemental groups if they share documents.
>
> -Steve
>
>
> > On Sat, May 23, 2015 at 1:07 AM, Burn Alting <burn@swtf.dyndns.org> wrote:
> > > Guillaume,
> > >
> > > The only way I can think of, is to write a pam module, similar to
> > > Steve's pam_loginuid.
> > >
> > > The module would need to gain the user's ssh key and use that to look up
> > > some database that maps the key to a uid. The uid can then be applied to
> > > the loginuid in the proc structure.
> > >
> > > Regards
> > >
> > > On Fri, 2015-05-15 at 15:09 +0200, Guillaume L. wrote:
> > > > Hello,
> > > >
> > > >
> > > > Is there a way to log with auditd exported variables through ssd ?
> > > >
> > > >
> > > > My servers are used by many users but with the same account. So, I
> > > > export the SSH_USER variable from our "bastion" (where each user has a
> > > > specific account). With this configuration I can retrieve the remote
> > > > login.
> > > >
> > > >
> > > > I use this script in /etc/profile.d/:
> > > >
> > > >
> > > >
> > > > logger -p local0.notice "`date` ": Connection from $SSH_USER@`echo
> > > > $SSH_CONNECTION | cut -d " " -f1`":"`echo $SSH_CONNECTION | cut -d " "
> > > > -f2` for $USER
> > > >
> > > >
> > > > ($SSH_USER is the variable exported via SSHD)
> > > >
> > > >
> > > > The ultimate goal is to match the following log with the "remote
> > > > user" (because all users use the uid 1000 to connect to the server):
> > > >
> > > >
> > > > type=SYSCALL msg=audit(1431694892.457:37824): arch=c000003e syscall=59
> > > > success=yes exit=0 a0=14cea68 a1=1423a48 a2=1553008 a3=0 items=2
> > > > ppid=30894 pid=30947 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> > > > egid=0 sgid=0 fsgid=0 tty=pts3 ses=17 comm="ls" exe="/bin/ls"
> > > > key="auditcmd"
> > > > type=EXECVE msg=audit(1431694892.457:37824): argc=1 a0="ls"
> > > >
> > > >
> > > > type=CWD msg=audit(1431694892.457:37824): cwd="/root"
> > > >
> > > >
> > > > type=PATH msg=audit(1431694892.457:37824): item=0 name="/bin/ls"
> > > > inode=157 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> > > > nametype=NORMAL
> > > > type=PATH msg=audit(1431694892.457:37824): item=1 name=(null)
> > > > inode=4212 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> > > > nametype=NORMAL
> > > > type=PROCTITLE msg=audit(1431694892.457:37824): proctitle="ls"
> > > >
> > > >
> > > > Thank you in advance.
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > > --
> > > > Guillaume
> > > > --
> > > > Linux-audit mailing list
> > > > Linux-audit@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/linux-audit
>
^ permalink raw reply
* Re: auditd and SSHD exported variables
From: Steve Grubb @ 2015-05-25 22:09 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAGi3UzoZY1ShycGvoWjp1wASGv3BP9yHeTEFzFsxwOxHAM1XUQ@mail.gmail.com>
On Monday, May 25, 2015 09:37:33 AM Guillaume L. wrote:
> Hello,
>
> Thank you for your response.
>
> I hoped that there are another ways to do this :)
>
> I will explore pam to try to create a module !
The audit system in its entirety is designed with the assumption that each
user has their own account. Its for this reason that all security guidance
asks that root logins be disallowed. (Root is typically a shared account and
you cannot tell who did what if root logins were allowed.)
I'm not sure of the use case. Perhaps it really doesn't matter to have an
audit trail. But without any knowledge of the problem that one common account
solves, I say that you might consider giving people different accounts and use
supplemental groups if they share documents.
-Steve
> On Sat, May 23, 2015 at 1:07 AM, Burn Alting <burn@swtf.dyndns.org> wrote:
> > Guillaume,
> >
> > The only way I can think of, is to write a pam module, similar to
> > Steve's pam_loginuid.
> >
> > The module would need to gain the user's ssh key and use that to look up
> > some database that maps the key to a uid. The uid can then be applied to
> > the loginuid in the proc structure.
> >
> > Regards
> >
> > On Fri, 2015-05-15 at 15:09 +0200, Guillaume L. wrote:
> > > Hello,
> > >
> > >
> > > Is there a way to log with auditd exported variables through ssd ?
> > >
> > >
> > > My servers are used by many users but with the same account. So, I
> > > export the SSH_USER variable from our "bastion" (where each user has a
> > > specific account). With this configuration I can retrieve the remote
> > > login.
> > >
> > >
> > > I use this script in /etc/profile.d/:
> > >
> > >
> > >
> > > logger -p local0.notice "`date` ": Connection from $SSH_USER@`echo
> > > $SSH_CONNECTION | cut -d " " -f1`":"`echo $SSH_CONNECTION | cut -d " "
> > > -f2` for $USER
> > >
> > >
> > > ($SSH_USER is the variable exported via SSHD)
> > >
> > >
> > > The ultimate goal is to match the following log with the "remote
> > > user" (because all users use the uid 1000 to connect to the server):
> > >
> > >
> > > type=SYSCALL msg=audit(1431694892.457:37824): arch=c000003e syscall=59
> > > success=yes exit=0 a0=14cea68 a1=1423a48 a2=1553008 a3=0 items=2
> > > ppid=30894 pid=30947 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> > > egid=0 sgid=0 fsgid=0 tty=pts3 ses=17 comm="ls" exe="/bin/ls"
> > > key="auditcmd"
> > > type=EXECVE msg=audit(1431694892.457:37824): argc=1 a0="ls"
> > >
> > >
> > > type=CWD msg=audit(1431694892.457:37824): cwd="/root"
> > >
> > >
> > > type=PATH msg=audit(1431694892.457:37824): item=0 name="/bin/ls"
> > > inode=157 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> > > nametype=NORMAL
> > > type=PATH msg=audit(1431694892.457:37824): item=1 name=(null)
> > > inode=4212 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> > > nametype=NORMAL
> > > type=PROCTITLE msg=audit(1431694892.457:37824): proctitle="ls"
> > >
> > >
> > > Thank you in advance.
> > >
> > >
> > > Regards,
> > >
> > >
> > >
> > > --
> > > Guillaume
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: auditd and SSHD exported variables
From: Guillaume L. @ 2015-05-25 7:37 UTC (permalink / raw)
To: burn; +Cc: linux-audit
In-Reply-To: <1432336074.3118.17.camel@swtf.swtf.dyndns.org>
[-- Attachment #1.1: Type: text/plain, Size: 2386 bytes --]
Hello,
Thank you for your response.
I hoped that there are another ways to do this :)
I will explore pam to try to create a module !
--
Guillaume
On Sat, May 23, 2015 at 1:07 AM, Burn Alting <burn@swtf.dyndns.org> wrote:
> Guillaume,
>
> The only way I can think of, is to write a pam module, similar to
> Steve's pam_loginuid.
>
> The module would need to gain the user's ssh key and use that to look up
> some database that maps the key to a uid. The uid can then be applied to
> the loginuid in the proc structure.
>
> Regards
>
> On Fri, 2015-05-15 at 15:09 +0200, Guillaume L. wrote:
> > Hello,
> >
> >
> > Is there a way to log with auditd exported variables through ssd ?
> >
> >
> > My servers are used by many users but with the same account. So, I
> > export the SSH_USER variable from our "bastion" (where each user has a
> > specific account). With this configuration I can retrieve the remote
> > login.
> >
> >
> > I use this script in /etc/profile.d/:
> >
> >
> >
> > logger -p local0.notice "`date` ": Connection from $SSH_USER@`echo
> > $SSH_CONNECTION | cut -d " " -f1`":"`echo $SSH_CONNECTION | cut -d " "
> > -f2` for $USER
> >
> >
> > ($SSH_USER is the variable exported via SSHD)
> >
> >
> > The ultimate goal is to match the following log with the "remote
> > user" (because all users use the uid 1000 to connect to the server):
> >
> >
> > type=SYSCALL msg=audit(1431694892.457:37824): arch=c000003e syscall=59
> > success=yes exit=0 a0=14cea68 a1=1423a48 a2=1553008 a3=0 items=2
> > ppid=30894 pid=30947 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> > egid=0 sgid=0 fsgid=0 tty=pts3 ses=17 comm="ls" exe="/bin/ls"
> > key="auditcmd"
> > type=EXECVE msg=audit(1431694892.457:37824): argc=1 a0="ls"
> >
> >
> > type=CWD msg=audit(1431694892.457:37824): cwd="/root"
> >
> >
> > type=PATH msg=audit(1431694892.457:37824): item=0 name="/bin/ls"
> > inode=157 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> > nametype=NORMAL
> > type=PATH msg=audit(1431694892.457:37824): item=1 name=(null)
> > inode=4212 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> > nametype=NORMAL
> > type=PROCTITLE msg=audit(1431694892.457:37824): proctitle="ls"
> >
> >
> > Thank you in advance.
> >
> >
> > Regards,
> >
> >
> >
> > --
> > Guillaume
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 3598 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH] kernel:audit - Fix for typo in comment to function audit_log_link_denied().
From: Shailendra Verma @ 2015-05-23 5:10 UTC (permalink / raw)
To: Paul Moore, Eric Paris, linux-audit; +Cc: linux-kernel, Shailendra Verma
Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com>
---
kernel/audit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 1c13e42..f9e6065 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1904,7 +1904,7 @@ EXPORT_SYMBOL(audit_log_task_info);
/**
* audit_log_link_denied - report a link restriction denial
- * @operation: specific link opreation
+ * @operation: specific link operation
* @link: the path that triggered the restriction
*/
void audit_log_link_denied(const char *operation, struct path *link)
--
1.7.9.5
^ permalink raw reply related
* Re: auditd and SSHD exported variables
From: Burn Alting @ 2015-05-22 23:07 UTC (permalink / raw)
To: Guillaume L.; +Cc: linux-audit
In-Reply-To: <CAGi3Uzor4HCE1A7dfGyybVemFvx14-aZ46K_4CxKLhYCJ+HYnA@mail.gmail.com>
Guillaume,
The only way I can think of, is to write a pam module, similar to
Steve's pam_loginuid.
The module would need to gain the user's ssh key and use that to look up
some database that maps the key to a uid. The uid can then be applied to
the loginuid in the proc structure.
Regards
On Fri, 2015-05-15 at 15:09 +0200, Guillaume L. wrote:
> Hello,
>
>
> Is there a way to log with auditd exported variables through ssd ?
>
>
> My servers are used by many users but with the same account. So, I
> export the SSH_USER variable from our "bastion" (where each user has a
> specific account). With this configuration I can retrieve the remote
> login.
>
>
> I use this script in /etc/profile.d/:
>
>
>
> logger -p local0.notice "`date` ": Connection from $SSH_USER@`echo
> $SSH_CONNECTION | cut -d " " -f1`":"`echo $SSH_CONNECTION | cut -d " "
> -f2` for $USER
>
>
> ($SSH_USER is the variable exported via SSHD)
>
>
> The ultimate goal is to match the following log with the "remote
> user" (because all users use the uid 1000 to connect to the server):
>
>
> type=SYSCALL msg=audit(1431694892.457:37824): arch=c000003e syscall=59
> success=yes exit=0 a0=14cea68 a1=1423a48 a2=1553008 a3=0 items=2
> ppid=30894 pid=30947 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
> egid=0 sgid=0 fsgid=0 tty=pts3 ses=17 comm="ls" exe="/bin/ls"
> key="auditcmd"
> type=EXECVE msg=audit(1431694892.457:37824): argc=1 a0="ls"
>
>
> type=CWD msg=audit(1431694892.457:37824): cwd="/root"
>
>
> type=PATH msg=audit(1431694892.457:37824): item=0 name="/bin/ls"
> inode=157 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> nametype=NORMAL
> type=PATH msg=audit(1431694892.457:37824): item=1 name=(null)
> inode=4212 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> nametype=NORMAL
> type=PROCTITLE msg=audit(1431694892.457:37824): proctitle="ls"
>
>
> Thank you in advance.
>
>
> Regards,
>
>
>
> --
> Guillaume
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [PATCH 1/2] security: lsm_audit: add ioctl specific auditing
From: Steve Grubb @ 2015-05-20 20:39 UTC (permalink / raw)
To: Stephen Smalley
Cc: linux-audit, Paul Moore, Jeff Vander Stoep, eparis,
linux-security-module, james.l.morris, selinux, serge
In-Reply-To: <555CED00.9010208@tycho.nsa.gov>
On Wednesday, May 20, 2015 04:22:24 PM Stephen Smalley wrote:
> On 05/20/2015 04:21 PM, Steve Grubb wrote:
> > On Wednesday, May 20, 2015 04:06:55 PM Paul Moore wrote:
> >> On Thursday, April 09, 2015 02:49:31 PM Jeff Vander Stoep wrote:
> >>> Add information about ioctl calls to the LSM audit data. Log the
> >>> file path and command number.
> >>>
> >>> Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
> >>> ---
> >>>
> >>> include/linux/lsm_audit.h | 7 +++++++
> >>> security/lsm_audit.c | 15 +++++++++++++++
> >>> 2 files changed, 22 insertions(+)
> >>
> >> No real comment other than we should include the linux-audit list on this
> >> patch (added to the To/CC line).
> >>
> >> From an audit perspective the only new field would be the ioctl number
> >> which is represented by the "ioctlcmd" name. Does anyone in the audit
> >> space have any strong feelings on this one way or another?
> >
> > Isn't that in arg1 already? I know I wrote interpretations for it.
>
> Only with syscall audit, often not enabled. This is to capture the
> information on AVC denials for an extension to SELinux to support ioctl
> whitelisting.
OK. ioctlcmd is fine. I'll add it to the lookup table to interpret the value.
-Steve
^ permalink raw reply
* Re: [PATCH 1/2] security: lsm_audit: add ioctl specific auditing
From: Stephen Smalley @ 2015-05-20 20:22 UTC (permalink / raw)
To: Steve Grubb, linux-audit
Cc: Paul Moore, Jeff Vander Stoep, eparis, linux-security-module,
james.l.morris, selinux, serge
In-Reply-To: <11866875.LIkutgAE8Q@x2>
On 05/20/2015 04:21 PM, Steve Grubb wrote:
> On Wednesday, May 20, 2015 04:06:55 PM Paul Moore wrote:
>> On Thursday, April 09, 2015 02:49:31 PM Jeff Vander Stoep wrote:
>>> Add information about ioctl calls to the LSM audit data. Log the
>>> file path and command number.
>>>
>>> Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
>>> ---
>>>
>>> include/linux/lsm_audit.h | 7 +++++++
>>> security/lsm_audit.c | 15 +++++++++++++++
>>> 2 files changed, 22 insertions(+)
>>
>> No real comment other than we should include the linux-audit list on this
>> patch (added to the To/CC line).
>>
>> From an audit perspective the only new field would be the ioctl number
>> which is represented by the "ioctlcmd" name. Does anyone in the audit space
>> have any strong feelings on this one way or another?
>
> Isn't that in arg1 already? I know I wrote interpretations for it.
Only with syscall audit, often not enabled. This is to capture the
information on AVC denials for an extension to SELinux to support ioctl
whitelisting.
^ permalink raw reply
* Re: [PATCH 1/2] security: lsm_audit: add ioctl specific auditing
From: Steve Grubb @ 2015-05-20 20:21 UTC (permalink / raw)
To: linux-audit
Cc: Paul Moore, Jeff Vander Stoep, sds, eparis, linux-security-module,
james.l.morris, selinux, serge
In-Reply-To: <3322194.9bHnmkPx3f@sifl>
On Wednesday, May 20, 2015 04:06:55 PM Paul Moore wrote:
> On Thursday, April 09, 2015 02:49:31 PM Jeff Vander Stoep wrote:
> > Add information about ioctl calls to the LSM audit data. Log the
> > file path and command number.
> >
> > Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
> > ---
> >
> > include/linux/lsm_audit.h | 7 +++++++
> > security/lsm_audit.c | 15 +++++++++++++++
> > 2 files changed, 22 insertions(+)
>
> No real comment other than we should include the linux-audit list on this
> patch (added to the To/CC line).
>
> From an audit perspective the only new field would be the ioctl number
> which is represented by the "ioctlcmd" name. Does anyone in the audit space
> have any strong feelings on this one way or another?
Isn't that in arg1 already? I know I wrote interpretations for it.
-Steve
> > diff --git a/include/linux/lsm_audit.h b/include/linux/lsm_audit.h
> > index 1cc89e9..ffb9c9d 100644
> > --- a/include/linux/lsm_audit.h
> > +++ b/include/linux/lsm_audit.h
> > @@ -40,6 +40,11 @@ struct lsm_network_audit {
> >
> > } fam;
> >
> > };
> >
> > +struct lsm_ioctlop_audit {
> > + struct path path;
> > + u16 cmd;
> > +};
> > +
> >
> > /* Auxiliary data to use in generating the audit record. */
> > struct common_audit_data {
> >
> > char type;
> >
> > @@ -53,6 +58,7 @@ struct common_audit_data {
> >
> > #define LSM_AUDIT_DATA_KMOD 8
> > #define LSM_AUDIT_DATA_INODE 9
> > #define LSM_AUDIT_DATA_DENTRY 10
> >
> > +#define LSM_AUDIT_DATA_IOCTL_OP 11
> >
> > union {
> >
> > struct path path;
> > struct dentry *dentry;
> >
> > @@ -68,6 +74,7 @@ struct common_audit_data {
> >
> > } key_struct;
> >
> > #endif
> >
> > char *kmod_name;
> >
> > + struct lsm_ioctlop_audit *op;
> >
> > } u;
> > /* this union contains LSM specific data */
> > union {
> >
> > diff --git a/security/lsm_audit.c b/security/lsm_audit.c
> > index 69fdf3b..7147c17 100644
> > --- a/security/lsm_audit.c
> > +++ b/security/lsm_audit.c
> > @@ -245,6 +245,21 @@ static void dump_common_audit_data(struct
> > audit_buffer
> > *ab, }
> >
> > break;
> >
> > }
> >
> > + case LSM_AUDIT_DATA_IOCTL_OP: {
> > + struct inode *inode;
> > +
> > + audit_log_d_path(ab, " path=", &a->u.op->path);
> > +
> > + inode = a->u.op->path.dentry->d_inode;
> > + if (inode) {
> > + audit_log_format(ab, " dev=");
> > + audit_log_untrustedstring(ab, inode->i_sb->s_id);
> > + audit_log_format(ab, " ino=%lu", inode->i_ino);
> > + }
> > +
> > + audit_log_format(ab, " ioctlcmd=%hx", a->u.op->cmd);
> > + break;
> > + }
> >
> > case LSM_AUDIT_DATA_DENTRY: {
> >
> > struct inode *inode;
^ permalink raw reply
* Re: [PATCH 1/2] security: lsm_audit: add ioctl specific auditing
From: Paul Moore @ 2015-05-20 20:06 UTC (permalink / raw)
To: Jeff Vander Stoep, sds, linux-audit
Cc: selinux, linux-security-module, eparis, serge, james.l.morris
In-Reply-To: <1428616171-14767-1-git-send-email-jeffv@google.com>
On Thursday, April 09, 2015 02:49:31 PM Jeff Vander Stoep wrote:
> Add information about ioctl calls to the LSM audit data. Log the
> file path and command number.
>
> Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
> ---
> include/linux/lsm_audit.h | 7 +++++++
> security/lsm_audit.c | 15 +++++++++++++++
> 2 files changed, 22 insertions(+)
No real comment other than we should include the linux-audit list on this
patch (added to the To/CC line).
>From an audit perspective the only new field would be the ioctl number which
is represented by the "ioctlcmd" name. Does anyone in the audit space have
any strong feelings on this one way or another?
> diff --git a/include/linux/lsm_audit.h b/include/linux/lsm_audit.h
> index 1cc89e9..ffb9c9d 100644
> --- a/include/linux/lsm_audit.h
> +++ b/include/linux/lsm_audit.h
> @@ -40,6 +40,11 @@ struct lsm_network_audit {
> } fam;
> };
>
> +struct lsm_ioctlop_audit {
> + struct path path;
> + u16 cmd;
> +};
> +
> /* Auxiliary data to use in generating the audit record. */
> struct common_audit_data {
> char type;
> @@ -53,6 +58,7 @@ struct common_audit_data {
> #define LSM_AUDIT_DATA_KMOD 8
> #define LSM_AUDIT_DATA_INODE 9
> #define LSM_AUDIT_DATA_DENTRY 10
> +#define LSM_AUDIT_DATA_IOCTL_OP 11
> union {
> struct path path;
> struct dentry *dentry;
> @@ -68,6 +74,7 @@ struct common_audit_data {
> } key_struct;
> #endif
> char *kmod_name;
> + struct lsm_ioctlop_audit *op;
> } u;
> /* this union contains LSM specific data */
> union {
> diff --git a/security/lsm_audit.c b/security/lsm_audit.c
> index 69fdf3b..7147c17 100644
> --- a/security/lsm_audit.c
> +++ b/security/lsm_audit.c
> @@ -245,6 +245,21 @@ static void dump_common_audit_data(struct audit_buffer
> *ab, }
> break;
> }
> + case LSM_AUDIT_DATA_IOCTL_OP: {
> + struct inode *inode;
> +
> + audit_log_d_path(ab, " path=", &a->u.op->path);
> +
> + inode = a->u.op->path.dentry->d_inode;
> + if (inode) {
> + audit_log_format(ab, " dev=");
> + audit_log_untrustedstring(ab, inode->i_sb->s_id);
> + audit_log_format(ab, " ino=%lu", inode->i_ino);
> + }
> +
> + audit_log_format(ab, " ioctlcmd=%hx", a->u.op->cmd);
> + break;
> + }
> case LSM_AUDIT_DATA_DENTRY: {
> struct inode *inode;
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Paul Moore @ 2015-05-19 14:27 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Eric W. Biederman, Linux API, Linux Containers,
linux-kernel@vger.kernel.org, Andy Lutomirski, linux-audit,
Al Viro, Network Development, Linux FS Devel, Eric Paris,
Serge E. Hallyn
In-Reply-To: <20150519130911.GB20131@madcap2.tricolour.ca>
On Tue, May 19, 2015 at 9:09 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 15/05/16, Paul Moore wrote:
>> On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman wrote:
>> > It sounds nice but containers are not just a per process construct.
>> > Sometimes you might know anamespace but not which process instigated
>> > action to happen on that namespace.
>>
>> From an auditing perspective I'm not sure we will ever hit those
>> cases; did you have a particular example in mind?
>
> The example that immediately came to mind when I first read Eric's
> comment was a packet coming in off a network in a particular network
> namespace. That could narrow it down to a subset of containers based on
> which network namespace it inhabits, but since it isn't associated with
> a particular task yet (other than a kernel thread) it will not be
> possible to select the precise nsproxy, let alone the container.
Thanks, I was stuck thinking about syscall based auditing and forgot
about the various LSM based audit records. Of all people you would
think I would remember per-packet audit records ;)
Anyway, in this case I think including the namespace ID is sufficient,
largely because the container userspace doesn't have access to the
packet at this point. In order to actually receive the data the
container's userspace will need to issue a syscall where we can
include the container ID. An overly zealous security officer who
wants to trace all the kernel level audit events, like the one you
describe, can match up the namespace to a container in post-processing
if needed.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Richard Guy Briggs @ 2015-05-19 13:09 UTC (permalink / raw)
To: Paul Moore
Cc: Eric W. Biederman, Linux API, Linux Containers,
linux-kernel@vger.kernel.org, Andy Lutomirski, linux-audit,
Al Viro, Network Development, Linux FS Devel, Eric Paris,
Serge E. Hallyn
In-Reply-To: <CAHC9VhQs6pxFC3dvZic5XzuJr1xdJZyPjXdBoipwY3OOkng0ng@mail.gmail.com>
On 15/05/16, Paul Moore wrote:
> On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > Paul Moore <paul@paul-moore.com> writes:
> >> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >>> On 05/15/2015 05:05 PM, Paul Moore wrote:
> >>>> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
> >>>>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >>>>>> On 15/05/14, Paul Moore wrote:
> >>>>>>> * Look at our existing audit records to determine which records should
> >>>>>>> have
> >>>>>>> namespace and container ID tokens added. We may only want to add the
> >>>>>>> additional fields in the case where the namespace/container ID tokens are
> >>>>>>> not the init namespace.
> >>>>>> If we have a record that ties a set of namespace IDs with a container
> >>>>>> ID, then I expect we only need to list the containerID along with auid
> >>>>>> and sessionID.
> >>>>> The problem here is that the kernel has no concept of a "container", and I
> >>>>> don't think it makes any sense to add one just for audit. "Container" is a
> >>>>> marketing term used by some userspace tools.
> >>>>>
> >>>>> I can imagine that both audit could benefit from a concept of a
> >>>>> namespace *path* that understands nesting (e.g. root/2/5/1 or
> >>>>> something along those lines). Mapping these to "containers" belongs
> >>>>> in userspace, I think.
> >>>> It might be helpful to climb up a few levels in this thread ...
> >>>>
> >>>> I think we all agree that containers are not a kernel construct. I further
> >>>> believe that the kernel has no business generating container IDs, those should
> >>>> come from userspace and will likely be different depending on how you define
> >>>> "container". However, what is less clear to me at this point is how the
> >>>> kernel should handle the setting, reporting, and general management of this
> >>>> container ID token.
> >>>>
> >>> Wouldn't the easiest thing be to just treat add a containerid to the
> >>> process context like auid.
> >>
> >> I believe so. At least that was the point I was trying to get across
> >> when I first jumped into this thread.
> >
> > It sounds nice but containers are not just a per process construct.
> > Sometimes you might know anamespace but not which process instigated
> > action to happen on that namespace.
>
> >From an auditing perspective I'm not sure we will ever hit those
> cases; did you have a particular example in mind?
The example that immediately came to mind when I first read Eric's
comment was a packet coming in off a network in a particular network
namespace. That could narrow it down to a subset of containers based on
which network namespace it inhabits, but since it isn't associated with
a particular task yet (other than a kernel thread) it will not be
possible to select the precise nsproxy, let alone the container.
> paul moore
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Paul Moore @ 2015-05-16 22:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linux API, Linux Containers, Daniel J Walsh,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andy Lutomirski, Paul Moore, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
Al Viro, Network Development, Linux FS Devel, Eric Paris
In-Reply-To: <87r3qgpol6.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> writes:
>> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> On 05/15/2015 05:05 PM, Paul Moore wrote:
>>>> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
>>>>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>>>> On 15/05/14, Paul Moore wrote:
>>>>>>> * Look at our existing audit records to determine which records should
>>>>>>> have
>>>>>>> namespace and container ID tokens added. We may only want to add the
>>>>>>> additional fields in the case where the namespace/container ID tokens are
>>>>>>> not the init namespace.
>>>>>> If we have a record that ties a set of namespace IDs with a container
>>>>>> ID, then I expect we only need to list the containerID along with auid
>>>>>> and sessionID.
>>>>> The problem here is that the kernel has no concept of a "container", and I
>>>>> don't think it makes any sense to add one just for audit. "Container" is a
>>>>> marketing term used by some userspace tools.
>>>>>
>>>>> I can imagine that both audit could benefit from a concept of a
>>>>> namespace *path* that understands nesting (e.g. root/2/5/1 or
>>>>> something along those lines). Mapping these to "containers" belongs
>>>>> in userspace, I think.
>>>> It might be helpful to climb up a few levels in this thread ...
>>>>
>>>> I think we all agree that containers are not a kernel construct. I further
>>>> believe that the kernel has no business generating container IDs, those should
>>>> come from userspace and will likely be different depending on how you define
>>>> "container". However, what is less clear to me at this point is how the
>>>> kernel should handle the setting, reporting, and general management of this
>>>> container ID token.
>>>>
>>> Wouldn't the easiest thing be to just treat add a containerid to the
>>> process context like auid.
>>
>> I believe so. At least that was the point I was trying to get across
>> when I first jumped into this thread.
>
> It sounds nice but containers are not just a per process construct.
> Sometimes you might know anamespace but not which process instigated
> action to happen on that namespace.
>From an auditing perspective I'm not sure we will ever hit those
cases; did you have a particular example in mind?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Eric W. Biederman @ 2015-05-16 14:46 UTC (permalink / raw)
To: Paul Moore
Cc: Daniel J Walsh, Paul Moore, Andy Lutomirski, Serge E. Hallyn,
Richard Guy Briggs, Linux API, Linux Containers,
linux-kernel@vger.kernel.org, Al Viro,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA, Network Development,
Linux FS Devel, Eric Paris
In-Reply-To: <CAHC9VhRKSK9=9qPF3dgALS=x1g3LinNeQvuhNV5TvQ=D7Szuag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> writes:
> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On 05/15/2015 05:05 PM, Paul Moore wrote:
>>> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
>>>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>>> On 15/05/14, Paul Moore wrote:
>>>>>> * Look at our existing audit records to determine which records should
>>>>>> have
>>>>>> namespace and container ID tokens added. We may only want to add the
>>>>>> additional fields in the case where the namespace/container ID tokens are
>>>>>> not the init namespace.
>>>>> If we have a record that ties a set of namespace IDs with a container
>>>>> ID, then I expect we only need to list the containerID along with auid
>>>>> and sessionID.
>>>> The problem here is that the kernel has no concept of a "container", and I
>>>> don't think it makes any sense to add one just for audit. "Container" is a
>>>> marketing term used by some userspace tools.
>>>>
>>>> I can imagine that both audit could benefit from a concept of a
>>>> namespace *path* that understands nesting (e.g. root/2/5/1 or
>>>> something along those lines). Mapping these to "containers" belongs
>>>> in userspace, I think.
>>> It might be helpful to climb up a few levels in this thread ...
>>>
>>> I think we all agree that containers are not a kernel construct. I further
>>> believe that the kernel has no business generating container IDs, those should
>>> come from userspace and will likely be different depending on how you define
>>> "container". However, what is less clear to me at this point is how the
>>> kernel should handle the setting, reporting, and general management of this
>>> container ID token.
>>>
>> Wouldn't the easiest thing be to just treat add a containerid to the
>> process context like auid.
>
> I believe so. At least that was the point I was trying to get across
> when I first jumped into this thread.
It sounds nice but containers are not just a per process construct.
Sometimes you might know anamespace but not which process instigated
action to happen on that namespace.
>> Then make it a privileged operation to set it. Then tools that care about
>> auditing like docker can set the ID
>> and remove the Capability from it sub processes if it cares. All
>> processes adopt parent processes containerid.
>> Now containers can be audited and as long as userspace is written
>> correctly nested containers can either override the containerid or not
>> depending on what the audit rules are.
>
> This part I'm still less certain on. I agree that setting the
> container ID should be privileged in some sense, but the kernel
> shouldn't *require* privilege to create a new container (however the
> user chooses to define it). Simply requiring privilege to set the
> container ID and failing silently may be sufficient.
My hope is as things mature fewer and fewer container things will need
any special privilege to create.
I think it needs to start with a clear definition of what is wanted and
then working backwards through which messages in which contexts you want
to have your magic bits.
Eric
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Paul Moore @ 2015-05-16 12:16 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Paul Moore, Andy Lutomirski, Serge E. Hallyn, Richard Guy Briggs,
Linux API, Linux Containers, linux-kernel@vger.kernel.org,
Al Viro, linux-audit, Eric W. Biederman, Network Development,
Linux FS Devel, Eric Paris
In-Reply-To: <555711FA.50703@redhat.com>
On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> On 05/15/2015 05:05 PM, Paul Moore wrote:
>> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
>>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>>>> On 15/05/14, Paul Moore wrote:
>>>>> * Look at our existing audit records to determine which records should
>>>>> have
>>>>> namespace and container ID tokens added. We may only want to add the
>>>>> additional fields in the case where the namespace/container ID tokens are
>>>>> not the init namespace.
>>>> If we have a record that ties a set of namespace IDs with a container
>>>> ID, then I expect we only need to list the containerID along with auid
>>>> and sessionID.
>>> The problem here is that the kernel has no concept of a "container", and I
>>> don't think it makes any sense to add one just for audit. "Container" is a
>>> marketing term used by some userspace tools.
>>>
>>> I can imagine that both audit could benefit from a concept of a
>>> namespace *path* that understands nesting (e.g. root/2/5/1 or
>>> something along those lines). Mapping these to "containers" belongs
>>> in userspace, I think.
>> It might be helpful to climb up a few levels in this thread ...
>>
>> I think we all agree that containers are not a kernel construct. I further
>> believe that the kernel has no business generating container IDs, those should
>> come from userspace and will likely be different depending on how you define
>> "container". However, what is less clear to me at this point is how the
>> kernel should handle the setting, reporting, and general management of this
>> container ID token.
>>
> Wouldn't the easiest thing be to just treat add a containerid to the
> process context like auid.
I believe so. At least that was the point I was trying to get across
when I first jumped into this thread.
> Then make it a privileged operation to set it. Then tools that care about
> auditing like docker can set the ID
> and remove the Capability from it sub processes if it cares. All
> processes adopt parent processes containerid.
> Now containers can be audited and as long as userspace is written
> correctly nested containers can either override the containerid or not
> depending on what the audit rules are.
This part I'm still less certain on. I agree that setting the
container ID should be privileged in some sense, but the kernel
shouldn't *require* privilege to create a new container (however the
user chooses to define it). Simply requiring privilege to set the
container ID and failing silently may be sufficient.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Daniel J Walsh @ 2015-05-16 9:46 UTC (permalink / raw)
To: Paul Moore, Andy Lutomirski
Cc: Eric W. Biederman, Linux API, Linux Containers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA, Al Viro, Network Development,
Linux FS Devel, Eric Paris
In-Reply-To: <9125391.7ZiCneo6Xn@sifl>
On 05/15/2015 05:05 PM, Paul Moore wrote:
> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> On 15/05/14, Paul Moore wrote:
>>>> * Look at our existing audit records to determine which records should
>>>> have
>>>> namespace and container ID tokens added. We may only want to add the
>>>> additional fields in the case where the namespace/container ID tokens are
>>>> not the init namespace.
>>> If we have a record that ties a set of namespace IDs with a container
>>> ID, then I expect we only need to list the containerID along with auid
>>> and sessionID.
>> The problem here is that the kernel has no concept of a "container", and I
>> don't think it makes any sense to add one just for audit. "Container" is a
>> marketing term used by some userspace tools.
>>
>> I can imagine that both audit could benefit from a concept of a
>> namespace *path* that understands nesting (e.g. root/2/5/1 or
>> something along those lines). Mapping these to "containers" belongs
>> in userspace, I think.
> It might be helpful to climb up a few levels in this thread ...
>
> I think we all agree that containers are not a kernel construct. I further
> believe that the kernel has no business generating container IDs, those should
> come from userspace and will likely be different depending on how you define
> "container". However, what is less clear to me at this point is how the
> kernel should handle the setting, reporting, and general management of this
> container ID token.
>
Wouldn't the easiest thing be to just treat add a containerid to the
process context like auid. Then
make it a privileged operation to set it. Then tools that care about
auditing like docker can set the ID
and remove the Capability from it sub processes if it cares. All
processes adopt parent processes containerid.
Now containers can be audited and as long as userspace is written
correctly nested containers can either override the containerid or not
depending on what the audit rules are.
No special handling inside of namespaces.
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Paul Moore @ 2015-05-15 21:05 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Linux API, Linux Containers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Al Viro,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA, Eric W. Biederman,
Network Development, Linux FS Devel, Eric Paris, Steve Grubb,
Mimi Zohar
In-Reply-To: <CALCETrWzM4+Vs8OVJWBcWJfbR_DRSb+e7SmUyy6CS4sHQaTkRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On 15/05/14, Paul Moore wrote:
> >> * Look at our existing audit records to determine which records should
> >> have
> >> namespace and container ID tokens added. We may only want to add the
> >> additional fields in the case where the namespace/container ID tokens are
> >> not the init namespace.
> >
> > If we have a record that ties a set of namespace IDs with a container
> > ID, then I expect we only need to list the containerID along with auid
> > and sessionID.
>
> The problem here is that the kernel has no concept of a "container", and I
> don't think it makes any sense to add one just for audit. "Container" is a
> marketing term used by some userspace tools.
>
> I can imagine that both audit could benefit from a concept of a
> namespace *path* that understands nesting (e.g. root/2/5/1 or
> something along those lines). Mapping these to "containers" belongs
> in userspace, I think.
It might be helpful to climb up a few levels in this thread ...
I think we all agree that containers are not a kernel construct. I further
believe that the kernel has no business generating container IDs, those should
come from userspace and will likely be different depending on how you define
"container". However, what is less clear to me at this point is how the
kernel should handle the setting, reporting, and general management of this
container ID token.
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Paul Moore @ 2015-05-15 21:01 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Steve Grubb, Richard Guy Briggs, containers, linux-kernel,
linux-audit, eparis, arozansk, serge, zohar, viro, linux-fsdevel,
linux-api, netdev
In-Reply-To: <87bnhmbp8e.fsf@x220.int.ebiederm.org>
On Thursday, May 14, 2015 08:31:45 PM Eric W. Biederman wrote:
> Paul Moore <pmoore@redhat.com> writes:
> > As Eric, and others, have stated, the container concept is a userspace
> > idea, not a kernel idea; the kernel only knows, and cares about,
> > namespaces. This is unlikely to change.
> >
> > However, as Steve points out, there is precedence for the kernel to record
> > userspace tokens for the sake of audit. Personally I'm not a big fan of
> > this in general, but I do recognize that it does satisfy a legitimate
> > need. Think of things like auid and the sessionid as necessary evils;
> > audit is already chock full of evilness I doubt one more will doom us all
> > to hell.
> >
> > Moving forward, I'd like to see the following:
> >
> > * Create a container ID token (unsigned 32-bit integer?), similar to
> > auid/sessionid, that is set by userspace and carried by the kernel to be
> > used in audit records. I'd like to see some discussion on how we manage
> > this, e.g. how do handle container ID inheritance, how do we handle
> > nested containers (setting the containerid when it is already set), do we
> > care if multiple different containers share the same namespace config,
> > etc.?
> >
> >
> > Can we all live with this? If not, please suggest some alternate ideas;
> > simply shouting "IT'S ALL CRAP!" isn't helpful for anyone ... it may be
> > true, but it doesn't help us solve the problem ;)
>
> Without stopping and defining what someone means by container I think it
> is pretty much nonsense.
For what it is worth, I doubt we will ever arrive at a consistent definition
of a container. This is one of the reasons why I don't think we want the
kernel generating a container ID token, although I understand the real world
desire to have the kernel report such information back in the audit logs.
> Should every vsftp connection get a container every? Every chrome tab?
That's up to the individual system. I would argue that's a pretty silly
configuration, but one persons silliness is another's best practice. It's a
mad, mad world.
> At some of the connections per second numbers I have seen we might
> exhaust a 32bit number in an hour or two. Will any of that make sense
> to someone reading the audit logs?
If someone if going to spawn each process in a container then they will need
to live with the fallout of that decision.
Also, if folks thing 32-bits is too small, we can always do 64-bits, but I
don't think that was the point you were trying to make (I could be wrong).
> Without considerning that container creation is an unprivileged
> operation I think it is pretty much nonsense. Do I get to say I am any
> container I want? That would seem to invalidate the concept of
> userspace setting a container id.
>
> How does any of this interact with setns? AKA entering a container?
As I said in my email, I think we need some discussion around this; I don't
pretend to think we have this sorted at this point. I just want to make sure
were working towards some common ground instead of shouting the same stuff
back and forth at each other.
> I will go as far as looking at patches. If someone comes up with
> a mission statement about what they are actually trying to achieve and a
> mechanism that actually achieves that, and that allows for containers to
> nest we can talk about doing something like that.
I think Steve has posted some requirements that Richard is trying to satisfy
with these patches; we've also heard from at least one person who is looking
at how to deploy this in the Real World. Perhaps in the next round of patches
Richard can list the requirements in the 0/X patch and describe how they are
satisfied in the patchset.
Beyond that, and ignoring for a moment the whole "a container is not a
*thing*" argument, can I assume that the auditing of nested "containers" are
your main remaining concern at this point?
> But for right now I just hear proposals for things that make no sense
> and can not possibly work. Not least because it will require modifying
> every program that creates a container and who knows how many of them
> there are. Especially since you don't need to be root. Modifying
> /usr/bin/unshare seems a little far out to me.
I think it is very reasonable that there will be some container infrastructure
tools which would handle this, we're already seeing this happening now; asking
for minor changes to these infrastructure applications to support container
auditing doesn't seem like a significant ask to me. Also, to be perfectly
clear, if the applications aren't updated it isn't as if they will fail to
work, it is just that they won't be able to take advantage of the new
container auditing capabilities. That seems reasonable to me.
--
paul moore
security @ redhat
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox