* Re: Exported symbols removed in 2.5.2
From: Steve Grubb @ 2016-05-03 16:33 UTC (permalink / raw)
To: Laurent Bigonville; +Cc: linux-audit
In-Reply-To: <6c976322-72d3-d934-93c0-9695cbad6862@debian.org>
On Tuesday, May 03, 2016 05:15:01 PM Laurent Bigonville wrote:
> >> +#MISSING: 1:2.5.2-1# audit_send_user_message@Base 1:2.2.1
> >>
> >> audit_set_backlog_limit@Base 1:2.2.1
> >> audit_set_backlog_wait_time@Base 1:2.4.2
> >> audit_set_enabled@Base 1:2.2.1
> >>
> >> Is that expected that these 4 symbols have been removed?
> >
> > Yes. This corresponds to the changelog entry:
> >
> > - Revise function hiding technique to better protect audit ABI
> >
> > All functions missing are internal to the audit libraries and could cause
> > symbols collisions or worse if people start using them even though they
> > are
> > not declared in the library headers.
>
> In the private.h header file, I can see the following comment:
>
> // This is the main messaging function used internally
> // Don't hide it, it used to be a part of the public API!
> extern int audit_send_user_message(int fd, int type, hide_t hide_err,
> const char *message);
>
> So doesn't this warrant a soname bump then?
The answer is not simple. It was a hidden symbol:
hidden_proto(audit_send_user_message);
But I noticed that this broke at some point because it was hidden in old
releases but then suddenly started being visible. There has been no changes in
the hiding technique since the 1.2 release. My guess is that something changed
in gcc somewhere along the way that broke the hiding technique from Ulrich
Drepper's DSO programming guidelines.
The function was part of the public API in the 1.0.16 release. It was
deprecated/hidden in the 1.2 release which dates to 7-Apr 2006. Its been about
10 years that the function prototype has not been in libaudit.h. I would hope
that a missing prototype message would have been reported and fixed in the last
10 years. I have personally fixed use of the symbol in everything I know of 10
years ago.
The only problem people would have is in very old utilities they wrote a long
time ago, or very old versions of shadow-utils/pam. I wrote a script that
looks for that symbol in all elf files. I have to test on RHEL 4 to find the
symbol in any programs. So, I think you have a valid concern, but its been so
long that in practice it has worked itself out.
-Steve
^ permalink raw reply
* Re: Exported symbols removed in 2.5.2
From: Laurent Bigonville @ 2016-05-03 15:15 UTC (permalink / raw)
To: Steve Grubb, linux-audit
In-Reply-To: <5694853.buGQaZGD79@x2>
Le 03/05/16 à 17:10, Steve Grubb a écrit :
> On Tuesday, May 03, 2016 05:04:04 PM Laurent Bigonville wrote:
>> Hello,
>>
>> In debian, during the build of a package, we have a tool checking if
>> symbols are removed from shared librearies.
>>
>> With the 2.5.2 release, I get the following output:
>>
>> --- debian/libauparse0.symbols (libauparse0_1:2.5.2-1_amd64)
>> +++ dpkg-gensymbolsmB_9P2 2016-05-03 15:01:10.606713310 +0000
>> @@ -1,7 +1,7 @@
>> libauparse.so.0 libauparse0 #MINVER#
>> au_terminate_all_events@Base 1:2.5.1
>> - audit_strsplit@Base 1:2.4.2
>> - audit_strsplit_r@Base 1:2.4.2
>> +#MISSING: 1:2.5.2-1# audit_strsplit@Base 1:2.4.2
>> +#MISSING: 1:2.5.2-1# audit_strsplit_r@Base 1:2.4.2
>> auparse_add_callback@Base 1:2.2.1
>> auparse_destroy@Base 1:2.2.1
>> auparse_do_interpretation@Base 1:2.3.1
>> @@ -49,4 +49,4 @@
>> ausearch_clear@Base 1:2.2.1
>> ausearch_next_event@Base 1:2.2.1
>> ausearch_set_stop@Base 1:2.2.1
>> - set_escape_mode@Base 1:2.4.4
>> +#MISSING: 1:2.5.2-1# set_escape_mode@Base 1:2.4.4
>> dpkg-gensymbols: warning: some symbols or patterns disappeared in the
>> symbols file: see diff output below
>> dpkg-gensymbols: warning: debian/libaudit1/DEBIAN/symbols doesn't match
>> completely debian/libaudit1.symbols
>> --- debian/libaudit1.symbols (libaudit1_1:2.5.2-1_amd64)
>> +++ dpkg-gensymbolsQATT_C 2016-05-03 15:01:10.802717308 +0000
>> @@ -56,7 +56,7 @@
>> audit_rule_syscall_data@Base 1:2.2.1
>> audit_rule_syscallbyname_data@Base 1:2.2.1
>> audit_send@Base 1:2.2.1
>> - audit_send_user_message@Base 1:2.2.1
>> +#MISSING: 1:2.5.2-1# audit_send_user_message@Base 1:2.2.1
>> audit_set_backlog_limit@Base 1:2.2.1
>> audit_set_backlog_wait_time@Base 1:2.4.2
>> audit_set_enabled@Base 1:2.2.1
>>
>> Is that expected that these 4 symbols have been removed?
> Yes. This corresponds to the changelog entry:
>
> - Revise function hiding technique to better protect audit ABI
>
> All functions missing are internal to the audit libraries and could cause
> symbols collisions or worse if people start using them even though they are
> not declared in the library headers.
In the private.h header file, I can see the following comment:
// This is the main messaging function used internally
// Don't hide it, it used to be a part of the public API!
extern int audit_send_user_message(int fd, int type, hide_t hide_err,
const char *message);
So doesn't this warrant a soname bump then?
^ permalink raw reply
* Re: Exported symbols removed in 2.5.2
From: Steve Grubb @ 2016-05-03 15:10 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <87e29370-9812-9577-6558-e86d5f47072e@debian.org>
On Tuesday, May 03, 2016 05:04:04 PM Laurent Bigonville wrote:
> Hello,
>
> In debian, during the build of a package, we have a tool checking if
> symbols are removed from shared librearies.
>
> With the 2.5.2 release, I get the following output:
>
> --- debian/libauparse0.symbols (libauparse0_1:2.5.2-1_amd64)
> +++ dpkg-gensymbolsmB_9P2 2016-05-03 15:01:10.606713310 +0000
> @@ -1,7 +1,7 @@
> libauparse.so.0 libauparse0 #MINVER#
> au_terminate_all_events@Base 1:2.5.1
> - audit_strsplit@Base 1:2.4.2
> - audit_strsplit_r@Base 1:2.4.2
> +#MISSING: 1:2.5.2-1# audit_strsplit@Base 1:2.4.2
> +#MISSING: 1:2.5.2-1# audit_strsplit_r@Base 1:2.4.2
> auparse_add_callback@Base 1:2.2.1
> auparse_destroy@Base 1:2.2.1
> auparse_do_interpretation@Base 1:2.3.1
> @@ -49,4 +49,4 @@
> ausearch_clear@Base 1:2.2.1
> ausearch_next_event@Base 1:2.2.1
> ausearch_set_stop@Base 1:2.2.1
> - set_escape_mode@Base 1:2.4.4
> +#MISSING: 1:2.5.2-1# set_escape_mode@Base 1:2.4.4
> dpkg-gensymbols: warning: some symbols or patterns disappeared in the
> symbols file: see diff output below
> dpkg-gensymbols: warning: debian/libaudit1/DEBIAN/symbols doesn't match
> completely debian/libaudit1.symbols
> --- debian/libaudit1.symbols (libaudit1_1:2.5.2-1_amd64)
> +++ dpkg-gensymbolsQATT_C 2016-05-03 15:01:10.802717308 +0000
> @@ -56,7 +56,7 @@
> audit_rule_syscall_data@Base 1:2.2.1
> audit_rule_syscallbyname_data@Base 1:2.2.1
> audit_send@Base 1:2.2.1
> - audit_send_user_message@Base 1:2.2.1
> +#MISSING: 1:2.5.2-1# audit_send_user_message@Base 1:2.2.1
> audit_set_backlog_limit@Base 1:2.2.1
> audit_set_backlog_wait_time@Base 1:2.4.2
> audit_set_enabled@Base 1:2.2.1
>
> Is that expected that these 4 symbols have been removed?
Yes. This corresponds to the changelog entry:
- Revise function hiding technique to better protect audit ABI
All functions missing are internal to the audit libraries and could cause
symbols collisions or worse if people start using them even though they are
not declared in the library headers.
-Steve
^ permalink raw reply
* Exported symbols removed in 2.5.2
From: Laurent Bigonville @ 2016-05-03 15:04 UTC (permalink / raw)
To: linux-audit
Hello,
In debian, during the build of a package, we have a tool checking if
symbols are removed from shared librearies.
With the 2.5.2 release, I get the following output:
--- debian/libauparse0.symbols (libauparse0_1:2.5.2-1_amd64)
+++ dpkg-gensymbolsmB_9P2 2016-05-03 15:01:10.606713310 +0000
@@ -1,7 +1,7 @@
libauparse.so.0 libauparse0 #MINVER#
au_terminate_all_events@Base 1:2.5.1
- audit_strsplit@Base 1:2.4.2
- audit_strsplit_r@Base 1:2.4.2
+#MISSING: 1:2.5.2-1# audit_strsplit@Base 1:2.4.2
+#MISSING: 1:2.5.2-1# audit_strsplit_r@Base 1:2.4.2
auparse_add_callback@Base 1:2.2.1
auparse_destroy@Base 1:2.2.1
auparse_do_interpretation@Base 1:2.3.1
@@ -49,4 +49,4 @@
ausearch_clear@Base 1:2.2.1
ausearch_next_event@Base 1:2.2.1
ausearch_set_stop@Base 1:2.2.1
- set_escape_mode@Base 1:2.4.4
+#MISSING: 1:2.5.2-1# set_escape_mode@Base 1:2.4.4
dpkg-gensymbols: warning: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libaudit1/DEBIAN/symbols doesn't match
completely debian/libaudit1.symbols
--- debian/libaudit1.symbols (libaudit1_1:2.5.2-1_amd64)
+++ dpkg-gensymbolsQATT_C 2016-05-03 15:01:10.802717308 +0000
@@ -56,7 +56,7 @@
audit_rule_syscall_data@Base 1:2.2.1
audit_rule_syscallbyname_data@Base 1:2.2.1
audit_send@Base 1:2.2.1
- audit_send_user_message@Base 1:2.2.1
+#MISSING: 1:2.5.2-1# audit_send_user_message@Base 1:2.2.1
audit_set_backlog_limit@Base 1:2.2.1
audit_set_backlog_wait_time@Base 1:2.4.2
audit_set_enabled@Base 1:2.2.1
Is that expected that these 4 symbols have been removed?
Cheers,
Laurent Bigonville
^ permalink raw reply
* Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log
From: Paul Moore @ 2016-05-02 21:18 UTC (permalink / raw)
To: John Johansen; +Cc: linux-audit
In-Reply-To: <2439154.9hzZSnzZKD@x2>
On Fri, Apr 29, 2016 at 12:30 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Friday, April 29, 2016 07:07:06 PM Vincas Dargis wrote:
>> 2016.04.29 16:39, Steve Grubb rašė:
>> > You'll have to ask the AppArmor folks. I gave them a whole block of
>> > numbers to use for their own purposes so that we don't have any problems.
>> > If they instead create malformed SE Linux events, then things will never
>> > work right unless they patch them.
>>
>> Thank you for explanation, Steve. I'll bring this topic for them instead.
>
> Just to clarify, its not like I don't want this to work. I do. The intention
> of giving app armor its own block was that things its doing might not be a
> 100% fit for what SE Linux does. This was to give them the freedom to do their
> own thing. If they chose not to use the block and instead try to shoe-horn
> their events into a pre-existing one, there needs to be some discussion about
> how to make things right.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
[NOTE: I'm adding the AppArmor maintainer, John Johansen to this thread]
Hi John,
Heads-up, it looks like there might be some issues with AppArmor and auditing...
--
paul moore
security @ redhat
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: audit 2.5.1 released
From: Manuel Scunthorpe @ 2016-04-30 21:29 UTC (permalink / raw)
To: linux-audit@redhat.com
In-Reply-To: <543804231.8112760.1462051758161.JavaMail.yahoo.ref@mail.yahoo.com>
[-- Attachment #1.1: Type: text/plain, Size: 3471 bytes --]
Dear Steve,thanks for your helpful observations. I was able to modify the PKGBUILD and successfully build the package, and then build e4rat-lite which was my ultimate aim. Sadly it didn't seem to work in Arch Linux due to the kernel config options, e4rat-lite-collect didn't collect anything, complained about being unable to log anything due to a bad file descriptor and there was a message at boot saying Cannot open audit socket, which was similar to what auditctl said in the terminal. Of course it might work and I've got something else wrong, it doesn't look encouraging though without CONFIG_AUDIT enabled. But I was just looking at my Void Linux kernel options:CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
This looks more promising so I will have to try it here instead sometime, although what I will have to build to fulfill the various builddeps I don't yet know. Would it be OK if I tried to make an 'audit' package for Void Linux if they want one? There isn't one in the repo at present, so if I get a working build then I might as well share it. It could take a while to get to that point though, and that's assuming I can get everything to work in Void and don't end up using some other readahead utility altogether or accidentally corrupting my filesystem. But I can be happy I'm building audit correctly now.I will try and pass on your comments about zos servers and openldap-devel to the Arch packagers as I can only take credit for the confusion over the systemd support option in my earlier PKGBUILD.
Here's my successful modified PKGBUILD with the correct checksum for 2.5.1, which downloads and builds cleanly:# Edit /etc/makepkg.conf: staticlibs not !staticlibs or they are deleted by makepkg.
# $Id: PKGBUILD 146469 2015-11-10 05:04:55Z thestinger $
# Maintainer: Daniel Micay <danielmicay@gmail.com>
# Contributor: <kang@insecure.ws>
# Contributor: Massimiliano Torromeo <massimiliano.torromeo@gmail.com>
# Contributor: Connor Behan <connor.behan@gmail.com>
# Contributor: henning mueller <henning@orgizm.net>
pkgname=audit
pkgver=2.5.1
pkgrel=1
pkgdesc='Userspace components of the audit framework'
url='https://people.redhat.com/sgrubb/audit'
arch=(i686 x86_64)
depends=(krb5 libcap-ng)
makedepends=(libldap swig linux-headers python)
license=(GPL)
options=(emptydirs)
groups=('modified')
backup=(
etc/libaudit.conf
etc/audit/auditd.conf
etc/audisp/audispd.conf
etc/audisp/audisp-remote.conf
etc/audisp/plugins.d/af_unix.conf
etc/audisp/plugins.d/au-remote.conf
etc/audisp/plugins.d/syslog.conf
)
source=("$url/$pkgname-$pkgver.tar.gz")
sha256sums=('3c6ec72d8c16d1e85cc2b9c260cc6440319eb294cb54ca41a7bbe9283cc9f421')
install=$pkgname.install
build() {
cd $pkgname-$pkgver
export PYTHON=/usr/bin/python3
./configure \
--prefix=/usr \
--sbindir=/usr/bin \
--sysconfdir=/etc \
--libexecdir=/usr/lib/audit \
--with-python=yes \
--enable-gssapi-krb5=yes \
--enable-systemd=no \
--with-libcap-ng=yes \
--disable-zos-remote \
--enable-static=yes
make
}
package() {
cd $pkgname-$pkgver
make DESTDIR="$pkgdir" install
cd "$pkgdir"
install -d var/log/audit
rm -rf etc/rc.d etc/sysconfig usr/lib/audit
sed -ri 's|/sbin|/usr/bin|' \
etc/audit/*.conf \
etc/audisp/plugins.d/*.conf
[-- Attachment #1.2: Type: text/html, Size: 7249 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: audit review question
From: Warron S French @ 2016-04-29 20:21 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <2962003.0TmjEm8L5m@x2>
Thank you Steve. That is very helpful. Have a nice weekend.
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Friday, April 29, 2016 3:18 PM
To: Warron S French <warron.s.french@aero.org>
Cc: linux-audit@redhat.com
Subject: Re: audit review question
On Thursday, April 28, 2016 03:50:33 PM Warron S French wrote:
> Steve, thanks for your replies to all of my questions.
>
> Can you please send me a walk through document for trying to send the
> 6 workstations and 1 servers audit-data into the same directory structure?
> Something that will definitely work, please?
>
> I have a VM environment that I can make changes on and then test, so I
> would be very grateful for any cooperation I could get.
>
> My intent is to have all the machines log data to the same machine. I
> want the system security auditors to be able to use the typical
> aureport and ausearch commands (that I know you write).
>
> So, I have to ask, can this be done, and the audit logs be parsed on a
> per hostname-basis? Can they be stored in directories that are
> /var/log/audit/YYYY/MM/DD/Hostname_audit.log format - or is that
> inadvisable considering the intention to continue to support/use the two
> commands: aureport and ausearch? What would you advise - please?
The theory of operation is to put all events in one log and then separate them later by using a '--node' command line option.
> I am aware of the /etc/audisp directory, which I am sure is associated with
> the audispd daemon, but I don't have the foggiest clue of how to configure
> them together.
For a clear text transport
on the client side:
/etc/audisp/plugins.d/au-remote.conf
set active = yes
/etc/audisp/audisp-remote.conf
set remote_server = to the machine you are aggregating to
if you need lossless transport, set mode = forward
set local_port = 60
/etc/audisp/audispd.conf
name_format = HOSTNAME or another suitable option
On the server
/etc/audit/auditd.conf
set tcp_listen_port = 60
set tcp_client_ports = 60
set use_libwrap = yes
in /etc/hosts.allow
auditd: 1.2.4. or some subnet. You can read about all the tcp-wrappers config
options elsewhere.
restart the server
restart clients
To check if working:
ausearch --start recent -m DAEMON_ACCEPT -i
To get an encrypted transport, you need to use kerberos and that is beyond an
email for setting it up.
One of these days I'd like to add TLS as an option, too. But it'll be a little
longer. You might be able to vpn things to one another in the mean time. Or
maybe use a ssh tunnel.
> It is only because of stumbling around for the last 2 years (and very
> feverishly the last 2 days) that I have learned how to use the auditctl and
> aureport commands. I want to do this correctly, and I want to do it
> consistently with "industry standards" so that I can continue to get
> support from people like the folks in this 'forum.'
Sure.
-Steve
>
> Thanks, for any advice and useful links you can share. I am certain that as
> you provide them and I read them it will force me to ask even more
> questions. I hope you don't mind.
>
> Warron French, MBA, SCSA
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Thursday, April 28, 2016 11:10 AM
> To: linux-audit@redhat.com
> Cc: Warron S French <warron.s.french@aero.org>
> Subject: Re: audit review question
>
> On Wednesday, April 27, 2016 09:10:39 PM Warron S French wrote:
> > I have a scenario that I need a little help understanding how to work
> > through in an isolated environment of 1 server and 6 workstations (7
> > machines). The 7 machines are all running CentOS-6.7 and selinux =
> > disabled.
> >
> > All 6 workstations are configured through rsyslog.conf to send audit
> > data to the server, and I have (but apparently not successfully
> > configured general system messages to also report back to the same
> > server). I am using the conventional filesystems for each, but the
> > directory structure below is different.
>
> Rsyslog will likely mangle the audit lines such that its no longer in the
> native audit format. I don't know if its headers can be stripped as it
> writes to disk.
> > For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the
> > directory per day and per month and per year are auto created
> > (miraculously). For system messages, and I know this isn't the forum
> > to get help on this so I will only list the directory is -
> > /var/log/2016/04/27/wk{1..6}_syslog.log.
> >
> > Now that I am doing this, and successfully, I want to test that the
> > security auditors will be able to do their job properly, as well as I
> > am trying to comply with some security constraint that requires me to
> > centralize the logdata into a single server (hence the major driver for
> > all of this).
> >
> > I know that there is the aureport and ausearch command, but I am not
> > sure that I am able to figure out the correct command-line structure
> > to test that audit-data is getting into the appropriate file, on each
> > day of the year, on a per serverName basis.
> >
> > If a real-world situation occurred that the Security Auditors were
> > asking to find out how many machines did userX attempt to log into,
> > what would be the appropriate command for the example audit directory
> > I listed above (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because
> > I am not sure I am running the command with the appropriate switches
> > to scan the files properly?
> >
> > I used:
> >
> > * aureport -if /var/log/audit/2016/04/27/ and it didn't like the
> > input,
>
> Probably due to the header it inserts to each record. But this is how you
> should do it.
> > * aureport -if /var/log/audit/2016/04/27/* and it didn't like the
> > input, am I using the command improperly?
>
> You shouldn't need the '*'. If the passed option is a dir, then it
> automatically looks for more files. But note that the native rotation is
> audit.log <- newest
> audit.log.1
> audit.log.2
> audit.log.3 <- oldest
>
> rsyslog would also have to use this scheme. I have never investigated if it
> does. That does not means that a wrapper script couldn't be made to walk the
> files in rsyslog's order and send them to aureport via stdin. You could
> probably even add a sed command to strip the rsyslog headers from each
> record.
>
> Not the best answer, but once it hits rsyslog, it can change the record in
> ways that unknown to me.
>
> -Steve
^ permalink raw reply
* Re: Centralized Logging question #2
From: F Rafi @ 2016-04-29 20:05 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <2294046.2RPemcXKLg@x2>
[-- Attachment #1.1: Type: text/plain, Size: 1573 bytes --]
We're sysloging to a hosted search provider (somewhat like Splunk). They
don't currently support automatic auditd log parsing. However, we have
written custom scheduled alerts based on the syscalls we're logging.
I believe someone also posted a Splunk auditd app a while back.
https://splunkbase.splunk.com/app/2642/
-Farhan
On Fri, Apr 29, 2016 at 3:35 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Thursday, April 28, 2016 07:55:13 PM Warron S French wrote:
> > If I centralize audit logging through rsyslog, and I have each of the
> remote
> > machines' /etc/rsyslog.conf to use the same generic audit.log file name
> > instead of customizing the audit logs with something like;
> > HOSTNAME-audit.log, because ausearch apparently only looks for a file
> > specifically of the format audit.log...
>
> People who use rsyslog as the centralizing tool are likely to be using
> something else like splunk or other tools to do audit reporting and review.
>
>
> > Will the log-data submitted from the various hosts be consolidated into a
> > single file?
>
> Through the native audit tools, yes. Through other tools...I don't know.
> There
> are a variety of ways central logging can be done. I'm surprised no one has
> chimed in to offer an alternate.
>
>
> > Will the ausearch command then be usable with the -if argument?
>
> Once rsyslog gets the audit event, it adds its own data to the record. That
> messes up the audit tool's parsers.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
[-- Attachment #1.2: Type: text/html, Size: 2327 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Centralized Logging question #2
From: Steve Grubb @ 2016-04-29 19:35 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <BY1PR09MB088766EFFA19569A04DF45A4C7650@BY1PR09MB0887.namprd09.prod.outlook.com>
On Thursday, April 28, 2016 07:55:13 PM Warron S French wrote:
> If I centralize audit logging through rsyslog, and I have each of the remote
> machines' /etc/rsyslog.conf to use the same generic audit.log file name
> instead of customizing the audit logs with something like;
> HOSTNAME-audit.log, because ausearch apparently only looks for a file
> specifically of the format audit.log...
People who use rsyslog as the centralizing tool are likely to be using
something else like splunk or other tools to do audit reporting and review.
> Will the log-data submitted from the various hosts be consolidated into a
> single file?
Through the native audit tools, yes. Through other tools...I don't know. There
are a variety of ways central logging can be done. I'm surprised no one has
chimed in to offer an alternate.
> Will the ausearch command then be usable with the -if argument?
Once rsyslog gets the audit event, it adds its own data to the record. That
messes up the audit tool's parsers.
-Steve
^ permalink raw reply
* Re: audit review question
From: Steve Grubb @ 2016-04-29 19:18 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB088746CAA49369AE8FD23CE1C7650@BY1PR09MB0887.namprd09.prod.outlook.com>
On Thursday, April 28, 2016 03:50:33 PM Warron S French wrote:
> Steve, thanks for your replies to all of my questions.
>
> Can you please send me a walk through document for trying to send the 6
> workstations and 1 servers audit-data into the same directory structure?
> Something that will definitely work, please?
>
> I have a VM environment that I can make changes on and then test, so I would
> be very grateful for any cooperation I could get.
>
> My intent is to have all the machines log data to the same machine. I want
> the system security auditors to be able to use the typical aureport and
> ausearch commands (that I know you write).
>
> So, I have to ask, can this be done, and the audit logs be parsed on a per
> hostname-basis? Can they be stored in directories that are
> /var/log/audit/YYYY/MM/DD/Hostname_audit.log format - or is that
> inadvisable considering the intention to continue to support/use the two
> commands: aureport and ausearch? What would you advise - please?
The theory of operation is to put all events in one log and then separate them
later by using a '--node' command line option.
> I am aware of the /etc/audisp directory, which I am sure is associated with
> the audispd daemon, but I don't have the foggiest clue of how to configure
> them together.
For a clear text transport
on the client side:
/etc/audisp/plugins.d/au-remote.conf
set active = yes
/etc/audisp/audisp-remote.conf
set remote_server = to the machine you are aggregating to
if you need lossless transport, set mode = forward
set local_port = 60
/etc/audisp/audispd.conf
name_format = HOSTNAME or another suitable option
On the server
/etc/audit/auditd.conf
set tcp_listen_port = 60
set tcp_client_ports = 60
set use_libwrap = yes
in /etc/hosts.allow
auditd: 1.2.4. or some subnet. You can read about all the tcp-wrappers config
options elsewhere.
restart the server
restart clients
To check if working:
ausearch --start recent -m DAEMON_ACCEPT -i
To get an encrypted transport, you need to use kerberos and that is beyond an
email for setting it up.
One of these days I'd like to add TLS as an option, too. But it'll be a little
longer. You might be able to vpn things to one another in the mean time. Or
maybe use a ssh tunnel.
> It is only because of stumbling around for the last 2 years (and very
> feverishly the last 2 days) that I have learned how to use the auditctl and
> aureport commands. I want to do this correctly, and I want to do it
> consistently with "industry standards" so that I can continue to get
> support from people like the folks in this 'forum.'
Sure.
-Steve
>
> Thanks, for any advice and useful links you can share. I am certain that as
> you provide them and I read them it will force me to ask even more
> questions. I hope you don't mind.
>
> Warron French, MBA, SCSA
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Thursday, April 28, 2016 11:10 AM
> To: linux-audit@redhat.com
> Cc: Warron S French <warron.s.french@aero.org>
> Subject: Re: audit review question
>
> On Wednesday, April 27, 2016 09:10:39 PM Warron S French wrote:
> > I have a scenario that I need a little help understanding how to work
> > through in an isolated environment of 1 server and 6 workstations (7
> > machines). The 7 machines are all running CentOS-6.7 and selinux =
> > disabled.
> >
> > All 6 workstations are configured through rsyslog.conf to send audit
> > data to the server, and I have (but apparently not successfully
> > configured general system messages to also report back to the same
> > server). I am using the conventional filesystems for each, but the
> > directory structure below is different.
>
> Rsyslog will likely mangle the audit lines such that its no longer in the
> native audit format. I don't know if its headers can be stripped as it
> writes to disk.
> > For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the
> > directory per day and per month and per year are auto created
> > (miraculously). For system messages, and I know this isn't the forum
> > to get help on this so I will only list the directory is -
> > /var/log/2016/04/27/wk{1..6}_syslog.log.
> >
> > Now that I am doing this, and successfully, I want to test that the
> > security auditors will be able to do their job properly, as well as I
> > am trying to comply with some security constraint that requires me to
> > centralize the logdata into a single server (hence the major driver for
> > all of this).
> >
> > I know that there is the aureport and ausearch command, but I am not
> > sure that I am able to figure out the correct command-line structure
> > to test that audit-data is getting into the appropriate file, on each
> > day of the year, on a per serverName basis.
> >
> > If a real-world situation occurred that the Security Auditors were
> > asking to find out how many machines did userX attempt to log into,
> > what would be the appropriate command for the example audit directory
> > I listed above (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because
> > I am not sure I am running the command with the appropriate switches
> > to scan the files properly?
> >
> > I used:
> >
> > * aureport -if /var/log/audit/2016/04/27/ and it didn't like the
> > input,
>
> Probably due to the header it inserts to each record. But this is how you
> should do it.
> > * aureport -if /var/log/audit/2016/04/27/* and it didn't like the
> > input, am I using the command improperly?
>
> You shouldn't need the '*'. If the passed option is a dir, then it
> automatically looks for more files. But note that the native rotation is
> audit.log <- newest
> audit.log.1
> audit.log.2
> audit.log.3 <- oldest
>
> rsyslog would also have to use this scheme. I have never investigated if it
> does. That does not means that a wrapper script couldn't be made to walk the
> files in rsyslog's order and send them to aureport via stdin. You could
> probably even add a sed command to strip the rsyslog headers from each
> record.
>
> Not the best answer, but once it hits rsyslog, it can change the record in
> ways that unknown to me.
>
> -Steve
^ permalink raw reply
* Re: Excluding stat syscall logging for specific path
From: Vincas Dargis @ 2016-04-29 19:05 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <132907641.2oh64C0JXm@x2>
2016.04.29 21:48, Steve Grubb rašė:
>> No, there is no such file at all, and shouldn’t be, but apache2 tries to
>> check it, hence success=0 case is spammed into then logs.
>
> Normally ENOENT failures are not a security concern. Normally EACCES and EPERM
> are what attempted security policy violations return with. There is an inode
> in that case.
Yeah, now I am using -S open with EACCES/EPERM as from audit.rules example. Failed stat's ("scans") can actually be seen
from apache2 error.log.
> But it turns out that kernel doesn't matter this time.
Yes, It's clear for me now.
Thank you!
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Excluding stat syscall logging for specific path
From: Steve Grubb @ 2016-04-29 18:48 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5723A4F1.1030001@gmail.com>
On Friday, April 29, 2016 09:16:17 PM Vincas Dargis wrote:
> 2016.04.29 21:00, Steve Grubb rašė:
> > On Friday, April 29, 2016 08:56:26 PM Vincas Dargis wrote:
> >> When playing/learning with auditd, I wanted to log events when apache
> >> fails to access file.
> >>
> >> Here's the rules I used in Debian Wheezy (same on Jessie and and current
> >> latest Testing):
> >>
> >> -a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
> >> -a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
> >>
> >> /var/www/server-status file is non-existant,
> >
> > Is it a symlink? If it really doesn't exist, then there is no inode to
> > match against.
>
> Oh...
>
> No, there is no such file at all, and shouldn’t be, but apache2 tries to
> check it, hence success=0 case is spammed into then logs.
Normally ENOENT failures are not a security concern. Normally EACCES and EPERM
are what attempted security policy violations return with. There is an inode
in that case.
> Same with
> .htaccess files that apache2 tries to find in every directory...
>
> I though it is possible to exclude stat calls with that path as argument to
> the syscall, but if it actually needs physical inode... then I guess it
> makes sense why it does not work for me.
>
> I wanted to _ignore_ some known stat/open failures for non-existant files,
> to recap.
The granularity won't allow it unless you can find another unique attribute to
weed these out.
> > What kernel are you using?
>
> 3.2 and 3.16 for sure, and I believe I tested on Debian Testing so it should
> be 4.5 currently.
OK. There were some older kernels where this didn't work right and thought
that might be relevant. But it turns out that kernel doesn't matter this time.
> P.S. should I reply to all or just the list?
Doesn't matter. Mailman usually does the right thing.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Excluding stat syscall logging for specific path
From: Vincas Dargis @ 2016-04-29 18:16 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1734746.Y1sbE4bZ3d@x2>
2016.04.29 21:00, Steve Grubb rašė:
> On Friday, April 29, 2016 08:56:26 PM Vincas Dargis wrote:
>> Hi,
>>
>> When playing/learning with auditd, I wanted to log events when apache fails
>> to access file.
>>
>> Here's the rules I used in Debian Wheezy (same on Jessie and and current
>> latest Testing):
>>
>> -a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
>> -a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
>>
>> /var/www/server-status file is non-existant,
>
> Is it a symlink? If it really doesn't exist, then there is no inode to match
> against.
Oh...
No, there is no such file at all, and shouldn’t be, but apache2 tries to check it, hence success=0 case is spammed into
then logs. Same with .htaccess files that apache2 tries to find in every directory...
I though it is possible to exclude stat calls with that path as argument to the syscall, but if it actually needs
physical inode... then I guess it makes sense why it does not work for me.
I wanted to _ignore_ some known stat/open failures for non-existant files, to recap.
> What kernel are you using?
3.2 and 3.16 for sure, and I believe I tested on Debian Testing so it should be 4.5 currently.
P.S. should I reply to all or just the list?
Thanks.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Excluding stat syscall logging for specific path
From: Steve Grubb @ 2016-04-29 18:00 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5723A04A.6080208@gmail.com>
On Friday, April 29, 2016 08:56:26 PM Vincas Dargis wrote:
> Hi,
>
> When playing/learning with auditd, I wanted to log events when apache fails
> to access file.
>
> Here's the rules I used in Debian Wheezy (same on Jessie and and current
> latest Testing):
>
> -a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
> -a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
>
> /var/www/server-status file is non-existant,
Is it a symlink? If it really doesn't exist, then there is no inode to match
against.
> it's just alias for accessing
> mod_status information ( http://.../server-status path is accessed by munin
> regularly) so I wanted to minimise noise by that exit,never rule.
>
> But I can't get it work.
What kernel are you using?
-Steve
> I have more in-depth post in Debian forums [1] if that helps, but in short,
> should this work in general?
>
> Thanks!
>
> [1] http://forums.debian.net/viewtopic.php?f=5&t=128092
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Excluding stat syscall logging for specific path
From: Vincas Dargis @ 2016-04-29 17:56 UTC (permalink / raw)
To: linux-audit
Hi,
When playing/learning with auditd, I wanted to log events when apache fails to access file.
Here's the rules I used in Debian Wheezy (same on Jessie and and current latest Testing):
-a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
-a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
/var/www/server-status file is non-existant, it's just alias for accessing mod_status information (
http://.../server-status path is accessed by munin regularly) so I wanted to minimise noise by that exit,never rule.
But I can't get it work.
I have more in-depth post in Debian forums [1] if that helps, but in short, should this work in general?
Thanks!
[1] http://forums.debian.net/viewtopic.php?f=5&t=128092
^ permalink raw reply
* Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log
From: Vincas Dargis @ 2016-04-29 16:58 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20160429154131.GB18488@madcap2.tricolour.ca>
2016.04.29 18:41, Richard Guy Briggs rašė:
> You are welcome to your rant. I quite like mailing lists and IRC. I
> hate most other social media and forums. What do you suggest instead?
Hi,
I guess it's plain personal preference, but I just get annoyed once I have to deal with lists. That's why:
1. No explicit search function. Yes I know (_now_) that you can use your search engine with site: prefix, but that's too
"hidden" feature, and one have to "know" that from somewhere. I don't know why Mailman or (whatever that list engine is)
couldn't have at least search box that redirects to some search engine, if they don't want to incorporate local search
engine by themselves.
2. No (easy?) way to continue thread if not subscribed earlier. Debian bug tracker, that is based on email, does in fact
has "mbox" download link for specific post. But that's rarity I guess. In forums you just click "reply" button. In list,
you have to download .gz archive (which apparently failed in my latest Firefox 46 case) and edit it to make single .mbox
or whatever? ...
Steve suggested just to start new thread. Yeah, but.. that's kinda cheating, and issue still exists and I guess I am
(too) picky for these kind of usability "papprecuts", hence, the rant :-) .
3. Once subscribed, you may get lot's of lot's of emails, even if you are interested in only that single topic (or some
topics, maybe started long time ago), so you can just "lose"/forget/skip relevant reply. Meanwhile, forums have
notification function you cane enable for topics you are "watching".
4. No formatting options. It's sometimes hard to read code or other technical text embedded inside plain text email.
Meanwhile, using markdown/bbcode/whatever you can make technical keywords, file paths, or whole code blocks distinct
from plain text. Makes eyes happy.
Forums also have issues, like.. having gazillion of accounts (that simple email activation in lists makes it much easier
actually). Also, I imagine getting all list traffic by default might be good for maintainers who want to hear (ok, read)
all relevant issues. In forums, you should click-through all "highlighted" topics manually? Oh my...
Anyway, this off-topic should be in Mailman list probably :-) . All these are actually small, "bells-and-wistles",
"pappercut" issues I guess, but that's enough to make me *sigh* when I see I will have to deal with mailing list instead
of full-fledged bug tracker or at least a forum.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* audit 2.5.2 released
From: Steve Grubb @ 2016-04-29 16:57 UTC (permalink / raw)
To: linux-audit
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Fix memory leak caused by unneeded reference in auparse python bindings
- Revise function hiding technique to better protect audit ABI
- Interpret old-auid, exit syscall parameters
- Create local_events config option to auditd
- Create write_logs option for auditd and deprecate NOLOG log_format option
This release is mostly to get an updated auparse library in circulation that
does not have the memory leak in the get_timestamp function. Offhand I don't
know of any problems besides the one bug report. The bug has been there for
about 8 years with no other reports so it might not affect much. But, I'd
rather be safe than sorry.
The other things that people should be aware of is 2 new auditd configuration
options. In the last release there was an unannounced command line config
option to auditd, -a. This enabled an aggregate only mode. I decided long term
it might be better as a auditd.conf option. Its now the local_events option.
The default is "yes". If it's set to "no", then it only logs daemon and
network originating events. This allows the audit daemon to be put into a
container for the sole purpose of aggregating events from other systems.
The other new auditd.conf config option is write_logs. In working on the audit
event enrichment option, I found that we need to decouple an overused idiom in
the log_format option. There was a NOLOG option there that decides if we want
to write events to disk. But it turns out that we might not want to write
events to disk but we do want to enrich events for the plugins or remote
logging. That presents a conflict where we need to separate them. If you
currently have log_format = NOLOG, the you should now set write_logs = no. You
can then put log_format = raw and it won't do any harm. For the time being, a
NOLOG log_format setting will override write_logs to "no" so that its
backwards compatible.
Please let me know if you run across any problems with this release.
-Steve
^ permalink raw reply
* Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log
From: Steve Grubb @ 2016-04-29 16:30 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <572386AA.4030903@gmail.com>
On Friday, April 29, 2016 07:07:06 PM Vincas Dargis wrote:
> 2016.04.29 16:39, Steve Grubb rašė:
> > You'll have to ask the AppArmor folks. I gave them a whole block of
> > numbers to use for their own purposes so that we don't have any problems.
> > If they instead create malformed SE Linux events, then things will never
> > work right unless they patch them.
>
> Thank you for explanation, Steve. I'll bring this topic for them instead.
Just to clarify, its not like I don't want this to work. I do. The intention
of giving app armor its own block was that things its doing might not be a
100% fit for what SE Linux does. This was to give them the freedom to do their
own thing. If they chose not to use the block and instead try to shoe-horn
their events into a pre-existing one, there needs to be some discussion about
how to make things right.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log
From: Vincas Dargis @ 2016-04-29 16:07 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <20888678.3grpTmsTEK@x2>
2016.04.29 16:39, Steve Grubb rašė:
> You'll have to ask the AppArmor folks. I gave them a whole block of numbers to
> use for their own purposes so that we don't have any problems. If they instead
> create malformed SE Linux events, then things will never work right unless
> they patch them.
Thank you for explanation, Steve. I'll bring this topic for them instead.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log
From: Richard Guy Briggs @ 2016-04-29 15:41 UTC (permalink / raw)
To: Vincas Dargis; +Cc: linux-audit
In-Reply-To: <CAPNCXk2XY+bD6t7ZqkmE-Am24KqPw_6wraUc=6MhaRF7BZQ-cg@mail.gmail.com>
On 16/04/29, Vincas Dargis wrote:
> P.S. How do I actually reply to original thread that I did not
> received, since I just subscribed? I though I could maybe find raw
> message in archive https://www.redhat.com/archives/linux-audit/ but
> there aren't (no such message in 2014-May/Jun gz) . Oh how I hate
> using mailing lists so much... /rant.
The archives are a bit of a pain to download. I have found that
chromium, wget, curl all get messed up half-text half-compressed files
from this archive server, but firefox is able to download them properly.
The messages are all in the archives.
You are welcome to your rant. I quite like mailing lists and IRC. I
hate most other social media and forums. What do you suggest instead?
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: PID's Mapping
From: Richard Guy Briggs @ 2016-04-29 15:21 UTC (permalink / raw)
To: Deepika Sundar; +Cc: linux-audit
In-Reply-To: <CAHj_pNeSB_pFiatg=akB1PAqp5mTO+MLb7kNcmztL5nv+fFm6A@mail.gmail.com>
On 16/04/29, Deepika Sundar wrote:
> Thank you
> From init pid namespace How we can access the child pid-namespace PID's?
There are a number of helper functions and macros referenced in
include/linux/sched.h starting with task_pid() and following and in
kernel/pid.c and include/linux/pid.h. Some are with respect to initial
namespaces, some with respect to the current namespace and others work
with a namespace pointer.
> On 29-Apr-2016 7:33 pm, "Richard Guy Briggs" <rgb@redhat.com> wrote:
> > On 16/04/29, Deepika Sundar wrote:
> > > Thank You for the valuable Response RGB.
> > >
> > > As you mentioned in the above statement is what I was looking for, "There
> > > is a mapping from the PID in the initial PID namespace to its PID in a
> > > child PID namespace".
> > > As per your context, Is it initial PID namespace is the one which is get
> > > created in the "HOST"?
> >
> > If I understand your question, the first namespace of any type that is
> > created is the initial namespace. This set of 6 different namespace
> > types are the default that are created on a newly booted kernel.
> >
> > > Please provide me details about how to enter into INIT-PID namespace to
> > get
> > > the mappings of child PID Namespace.
> >
> > Generally, the init process (yes, the term "init" is a bit overloaded
> > here...) with PID 1 in the initial PID namespace is the starting point
> > for creating all other processes. (Some distributions have switched over
> > from using "init" to using "systemd" in this role.) If you are already
> > that process or you are a process that is a child of that process and
> > still in all the initial namespaces, you are already there. If you are
> > a process that is in a child PID namespace, you can't see any parent or
> > peer namespaces. This is intentional.
> >
> > > -DEEPIKA
> > >
> > > On Fri, Apr 29, 2016 at 8:07 AM, Richard Guy Briggs <rgb@redhat.com>
> > wrote:
> > >
> > > > On 16/04/28, Deepika Sundar wrote:
> > > > > Thank you for the replies.
> > > > >
> > > > > As per My understanding Root as Admin it has the control over all the
> > > > > namespaces.If this is correct,
> > > >
> > > > As per my previous email, not necessarily.
> > > >
> > > > > (i) Is that root should have access to all namespace relate info,
> > > > > for ex: PID's in the host is mapped to what PID's in the
> > Namespace?
> > > >
> > > > The initial PID namespace knows about all the PIDs on the machine since
> > > > the PID namespaces are hierarchical. There is a mapping from the PID
> > in
> > > > the initial PID namespace to its PID in a child PID namespace. A child
> > > > PID namespace should never be able to find out what its PID is in a
> > > > parent PID namespace.
> > > >
> > > > > if not ,
> > > > >
> > > > > (ii) Init should have only access to his own process and should not
> > have
> > > > > access to other namespace.
> > > >
> > > > See above.
> > > >
> > > > > Is this design limitation (or) Is it designed for better security ?
> > > >
> > > > Both.
> > > >
> > > > > On Wed, Apr 27, 2016 at 4:49 PM, Deepika Sundar <
> > > > sundar.deepika18@gmail.com> wrote:
> > > > > > As per rule root(admin) is the one who is monitoring the system's
> > > > > > information .so,there must exist some namespace information in proc
> > > > field
> > > > > > for the namespace related PID in global.Is this the way I'm
> > > > approaching to
> > > > > > the namespace related stuffs is correct?
> > > > > >
> > > > > > -Deepika
> > > > > >
> > > > > > On Mon, Apr 25, 2016 at 12:24 PM, Deepika Sundar <
> > > > > > sundar.deepika18@gmail.com> wrote:
> > > > > >
> > > > > >> Yeah.
> > > > > >> When the PID's which are in the namespace application has
> > different
> > > > PID
> > > > > >> compared to Global PID.There would be some means to map the
> > PID's in
> > > > the
> > > > > >> kernel level.Can anyone suggest How it can be mapped?
> > > > > >>
> > > > > >> On Wed, Apr 20, 2016 at 6:03 PM, Steve Grubb <sgrubb@redhat.com>
> > > > wrote:
> > > > > >>
> > > > > >>> On Wednesday, April 20, 2016 10:06:38 AM Deepika Sundar wrote:
> > > > > >>> > Is there any way that can be suggested as to map PID's of
> > > > namespace in
> > > > > >>> > global?
> > > > > >>>
> > > > > >>> This is on the TODO list. We have been kicking around several
> > ideas
> > > > but
> > > > > >>> have
> > > > > >>> not come to a conclusion about what exactly needs to be done. The
> > > > upshot
> > > > > >>> of
> > > > > >>> this is that basically containers have no support.
> > > > > >>>
> > > > > >>> -Steve
> > > > > >>>
> > > > > >>>
> > > > > >>> > On Mon, Apr 18, 2016 at 8:47 PM, Paul Moore <
> > paul@paul-moore.com>
> > > > > >>> wrote:
> > > > > >>> > > Please ask your question on the mailing list so that
> > everyone can
> > > > > >>> benefit.
> > > > > >>> > >
> > > > > >>> > > On Mon, Apr 18, 2016 at 1:34 AM, Deepika Sundar
> > > > > >>> > >
> > > > > >>> > > <sundar.deepika18@gmail.com> wrote:
> > > > > >>> > > > How it can be achieved ,Can I get any idea on this?
> > > > > >>> > > >
> > > > > >>> > > > On Fri, Apr 15, 2016 at 4:12 AM, Paul Moore <
> > > > paul@paul-moore.com>
> > > > > >>> wrote:
> > > > > >>> > > >> On Wed, Apr 13, 2016 at 1:43 AM, sowndarya kumar
> > > > > >>> > > >>
> > > > > >>> > > >> <sowndarya.nadar@gmail.com> wrote:
> > > > > >>> > > >> > Hi
> > > > > >>> > > >> >
> > > > > >>> > > >> > Is there any way to map the PID's seen in the namespace
> > > > > >>> application
> > > > > >>> > >
> > > > > >>> > > with
> > > > > >>> > >
> > > > > >>> > > >> > the
> > > > > >>> > > >> > PID's seen in global?
> > > > > >>> > > >> > If it can be done please provide the documentation or
> > idea
> > > > on
> > > > > >>> how it
> > > > > >>> > >
> > > > > >>> > > can
> > > > > >>> > >
> > > > > >>> > > >> > be
> > > > > >>> > > >> > done.
> > > > > >>> > > >>
> > > > > >>> > > >> In general the audit subsystem doesn't pay attention to
> > > > > >>> namespaces,
> > > > > >>> > > >> all PIDs reported to userspace are reported with respect
> > to
> > > > the
> > > > > >>> init
> > > > > >>> > > >> namespace.
> > > > > >>> > > >>
> > > > > >>> > > >> paul moore
> > > > > >>> > >
> > > > > >>> > > paul moore
> > > >
> > > > - RGB
> >
> > - RGB
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: PID's Mapping
From: Deepika Sundar @ 2016-04-29 14:06 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20160429140314.GN18994@madcap2.tricolour.ca>
[-- Attachment #1.1: Type: text/plain, Size: 6338 bytes --]
Thank you
>From init pid namespace How we can access the child pid-namespace PID's?
On 29-Apr-2016 7:33 pm, "Richard Guy Briggs" <rgb@redhat.com> wrote:
> On 16/04/29, Deepika Sundar wrote:
> > Thank You for the valuable Response RGB.
> >
> > As you mentioned in the above statement is what I was looking for, "There
> > is a mapping from the PID in the initial PID namespace to its PID in a
> > child PID namespace".
> > As per your context, Is it initial PID namespace is the one which is get
> > created in the "HOST"?
>
> If I understand your question, the first namespace of any type that is
> created is the initial namespace. This set of 6 different namespace
> types are the default that are created on a newly booted kernel.
>
> > Please provide me details about how to enter into INIT-PID namespace to
> get
> > the mappings of child PID Namespace.
>
> Generally, the init process (yes, the term "init" is a bit overloaded
> here...) with PID 1 in the initial PID namespace is the starting point
> for creating all other processes. (Some distributions have switched over
> from using "init" to using "systemd" in this role.) If you are already
> that process or you are a process that is a child of that process and
> still in all the initial namespaces, you are already there. If you are
> a process that is in a child PID namespace, you can't see any parent or
> peer namespaces. This is intentional.
>
> > -DEEPIKA
> >
> > On Fri, Apr 29, 2016 at 8:07 AM, Richard Guy Briggs <rgb@redhat.com>
> wrote:
> >
> > > On 16/04/28, Deepika Sundar wrote:
> > > > Thank you for the replies.
> > > >
> > > > As per My understanding Root as Admin it has the control over all the
> > > > namespaces.If this is correct,
> > >
> > > As per my previous email, not necessarily.
> > >
> > > > (i) Is that root should have access to all namespace relate info,
> > > > for ex: PID's in the host is mapped to what PID's in the
> Namespace?
> > >
> > > The initial PID namespace knows about all the PIDs on the machine since
> > > the PID namespaces are hierarchical. There is a mapping from the PID
> in
> > > the initial PID namespace to its PID in a child PID namespace. A child
> > > PID namespace should never be able to find out what its PID is in a
> > > parent PID namespace.
> > >
> > > > if not ,
> > > >
> > > > (ii) Init should have only access to his own process and should not
> have
> > > > access to other namespace.
> > >
> > > See above.
> > >
> > > > Is this design limitation (or) Is it designed for better security ?
> > >
> > > Both.
> > >
> > > > On Wed, Apr 27, 2016 at 4:49 PM, Deepika Sundar <
> > > sundar.deepika18@gmail.com> wrote:
> > > > > As per rule root(admin) is the one who is monitoring the system's
> > > > > information .so,there must exist some namespace information in proc
> > > field
> > > > > for the namespace related PID in global.Is this the way I'm
> > > approaching to
> > > > > the namespace related stuffs is correct?
> > > > >
> > > > > -Deepika
> > > > >
> > > > > On Mon, Apr 25, 2016 at 12:24 PM, Deepika Sundar <
> > > > > sundar.deepika18@gmail.com> wrote:
> > > > >
> > > > >> Yeah.
> > > > >> When the PID's which are in the namespace application has
> different
> > > PID
> > > > >> compared to Global PID.There would be some means to map the
> PID's in
> > > the
> > > > >> kernel level.Can anyone suggest How it can be mapped?
> > > > >>
> > > > >> On Wed, Apr 20, 2016 at 6:03 PM, Steve Grubb <sgrubb@redhat.com>
> > > wrote:
> > > > >>
> > > > >>> On Wednesday, April 20, 2016 10:06:38 AM Deepika Sundar wrote:
> > > > >>> > Is there any way that can be suggested as to map PID's of
> > > namespace in
> > > > >>> > global?
> > > > >>>
> > > > >>> This is on the TODO list. We have been kicking around several
> ideas
> > > but
> > > > >>> have
> > > > >>> not come to a conclusion about what exactly needs to be done. The
> > > upshot
> > > > >>> of
> > > > >>> this is that basically containers have no support.
> > > > >>>
> > > > >>> -Steve
> > > > >>>
> > > > >>>
> > > > >>> > On Mon, Apr 18, 2016 at 8:47 PM, Paul Moore <
> paul@paul-moore.com>
> > > > >>> wrote:
> > > > >>> > > Please ask your question on the mailing list so that
> everyone can
> > > > >>> benefit.
> > > > >>> > >
> > > > >>> > > On Mon, Apr 18, 2016 at 1:34 AM, Deepika Sundar
> > > > >>> > >
> > > > >>> > > <sundar.deepika18@gmail.com> wrote:
> > > > >>> > > > How it can be achieved ,Can I get any idea on this?
> > > > >>> > > >
> > > > >>> > > > On Fri, Apr 15, 2016 at 4:12 AM, Paul Moore <
> > > paul@paul-moore.com>
> > > > >>> wrote:
> > > > >>> > > >> On Wed, Apr 13, 2016 at 1:43 AM, sowndarya kumar
> > > > >>> > > >>
> > > > >>> > > >> <sowndarya.nadar@gmail.com> wrote:
> > > > >>> > > >> > Hi
> > > > >>> > > >> >
> > > > >>> > > >> > Is there any way to map the PID's seen in the namespace
> > > > >>> application
> > > > >>> > >
> > > > >>> > > with
> > > > >>> > >
> > > > >>> > > >> > the
> > > > >>> > > >> > PID's seen in global?
> > > > >>> > > >> > If it can be done please provide the documentation or
> idea
> > > on
> > > > >>> how it
> > > > >>> > >
> > > > >>> > > can
> > > > >>> > >
> > > > >>> > > >> > be
> > > > >>> > > >> > done.
> > > > >>> > > >>
> > > > >>> > > >> In general the audit subsystem doesn't pay attention to
> > > > >>> namespaces,
> > > > >>> > > >> all PIDs reported to userspace are reported with respect
> to
> > > the
> > > > >>> init
> > > > >>> > > >> namespace.
> > > > >>> > > >>
> > > > >>> > > >> --
> > > > >>> > > >> paul moore
> > > > >>> > > >> www.paul-moore.com
> > > > >>> > > >>
> > > > >>> > > >> --
> > > > >>> > > >> Linux-audit mailing list
> > > > >>> > > >> Linux-audit@redhat.com
> > > > >>> > > >> https://www.redhat.com/mailman/listinfo/linux-audit
> > > > >>> > >
> > > > >>> > > --
> > > > >>> > > paul moore
> > > > >>> > > www.paul-moore.com
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > >
> > > - RGB
> > >
> > > --
> > > Richard Guy Briggs <rgb@redhat.com>
> > > Kernel Security Engineering, Base Operating Systems, Red Hat
> > > Remote, Ottawa, Canada
> > > Voice: +1.647.777.2635, Internal: (81) 32635
> > >
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635
>
[-- Attachment #1.2: Type: text/html, Size: 10190 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: PID's Mapping
From: Richard Guy Briggs @ 2016-04-29 14:03 UTC (permalink / raw)
To: Deepika Sundar; +Cc: linux-audit
In-Reply-To: <CAHj_pNcmd8_ND4fE47NnVbFTWxus08XmETTjOoobyag+C4hoaA@mail.gmail.com>
On 16/04/29, Deepika Sundar wrote:
> Thank You for the valuable Response RGB.
>
> As you mentioned in the above statement is what I was looking for, "There
> is a mapping from the PID in the initial PID namespace to its PID in a
> child PID namespace".
> As per your context, Is it initial PID namespace is the one which is get
> created in the "HOST"?
If I understand your question, the first namespace of any type that is
created is the initial namespace. This set of 6 different namespace
types are the default that are created on a newly booted kernel.
> Please provide me details about how to enter into INIT-PID namespace to get
> the mappings of child PID Namespace.
Generally, the init process (yes, the term "init" is a bit overloaded
here...) with PID 1 in the initial PID namespace is the starting point
for creating all other processes. (Some distributions have switched over
from using "init" to using "systemd" in this role.) If you are already
that process or you are a process that is a child of that process and
still in all the initial namespaces, you are already there. If you are
a process that is in a child PID namespace, you can't see any parent or
peer namespaces. This is intentional.
> -DEEPIKA
>
> On Fri, Apr 29, 2016 at 8:07 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>
> > On 16/04/28, Deepika Sundar wrote:
> > > Thank you for the replies.
> > >
> > > As per My understanding Root as Admin it has the control over all the
> > > namespaces.If this is correct,
> >
> > As per my previous email, not necessarily.
> >
> > > (i) Is that root should have access to all namespace relate info,
> > > for ex: PID's in the host is mapped to what PID's in the Namespace?
> >
> > The initial PID namespace knows about all the PIDs on the machine since
> > the PID namespaces are hierarchical. There is a mapping from the PID in
> > the initial PID namespace to its PID in a child PID namespace. A child
> > PID namespace should never be able to find out what its PID is in a
> > parent PID namespace.
> >
> > > if not ,
> > >
> > > (ii) Init should have only access to his own process and should not have
> > > access to other namespace.
> >
> > See above.
> >
> > > Is this design limitation (or) Is it designed for better security ?
> >
> > Both.
> >
> > > On Wed, Apr 27, 2016 at 4:49 PM, Deepika Sundar <
> > sundar.deepika18@gmail.com> wrote:
> > > > As per rule root(admin) is the one who is monitoring the system's
> > > > information .so,there must exist some namespace information in proc
> > field
> > > > for the namespace related PID in global.Is this the way I'm
> > approaching to
> > > > the namespace related stuffs is correct?
> > > >
> > > > -Deepika
> > > >
> > > > On Mon, Apr 25, 2016 at 12:24 PM, Deepika Sundar <
> > > > sundar.deepika18@gmail.com> wrote:
> > > >
> > > >> Yeah.
> > > >> When the PID's which are in the namespace application has different
> > PID
> > > >> compared to Global PID.There would be some means to map the PID's in
> > the
> > > >> kernel level.Can anyone suggest How it can be mapped?
> > > >>
> > > >> On Wed, Apr 20, 2016 at 6:03 PM, Steve Grubb <sgrubb@redhat.com>
> > wrote:
> > > >>
> > > >>> On Wednesday, April 20, 2016 10:06:38 AM Deepika Sundar wrote:
> > > >>> > Is there any way that can be suggested as to map PID's of
> > namespace in
> > > >>> > global?
> > > >>>
> > > >>> This is on the TODO list. We have been kicking around several ideas
> > but
> > > >>> have
> > > >>> not come to a conclusion about what exactly needs to be done. The
> > upshot
> > > >>> of
> > > >>> this is that basically containers have no support.
> > > >>>
> > > >>> -Steve
> > > >>>
> > > >>>
> > > >>> > On Mon, Apr 18, 2016 at 8:47 PM, Paul Moore <paul@paul-moore.com>
> > > >>> wrote:
> > > >>> > > Please ask your question on the mailing list so that everyone can
> > > >>> benefit.
> > > >>> > >
> > > >>> > > On Mon, Apr 18, 2016 at 1:34 AM, Deepika Sundar
> > > >>> > >
> > > >>> > > <sundar.deepika18@gmail.com> wrote:
> > > >>> > > > How it can be achieved ,Can I get any idea on this?
> > > >>> > > >
> > > >>> > > > On Fri, Apr 15, 2016 at 4:12 AM, Paul Moore <
> > paul@paul-moore.com>
> > > >>> wrote:
> > > >>> > > >> On Wed, Apr 13, 2016 at 1:43 AM, sowndarya kumar
> > > >>> > > >>
> > > >>> > > >> <sowndarya.nadar@gmail.com> wrote:
> > > >>> > > >> > Hi
> > > >>> > > >> >
> > > >>> > > >> > Is there any way to map the PID's seen in the namespace
> > > >>> application
> > > >>> > >
> > > >>> > > with
> > > >>> > >
> > > >>> > > >> > the
> > > >>> > > >> > PID's seen in global?
> > > >>> > > >> > If it can be done please provide the documentation or idea
> > on
> > > >>> how it
> > > >>> > >
> > > >>> > > can
> > > >>> > >
> > > >>> > > >> > be
> > > >>> > > >> > done.
> > > >>> > > >>
> > > >>> > > >> In general the audit subsystem doesn't pay attention to
> > > >>> namespaces,
> > > >>> > > >> all PIDs reported to userspace are reported with respect to
> > the
> > > >>> init
> > > >>> > > >> namespace.
> > > >>> > > >>
> > > >>> > > >> --
> > > >>> > > >> paul moore
> > > >>> > > >> www.paul-moore.com
> > > >>> > > >>
> > > >>> > > >> --
> > > >>> > > >> Linux-audit mailing list
> > > >>> > > >> Linux-audit@redhat.com
> > > >>> > > >> https://www.redhat.com/mailman/listinfo/linux-audit
> > > >>> > >
> > > >>> > > --
> > > >>> > > paul moore
> > > >>> > > www.paul-moore.com
> > > >>>
> > > >>>
> > > >>
> > > >
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@redhat.com>
> > Kernel Security Engineering, Base Operating Systems, Red Hat
> > Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635
> >
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log
From: Steve Grubb @ 2016-04-29 13:39 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAPNCXk2XY+bD6t7ZqkmE-Am24KqPw_6wraUc=6MhaRF7BZQ-cg@mail.gmail.com>
On Friday, April 29, 2016 10:03:02 AM Vincas Dargis wrote:
> There was email about fixing ausearch for AppArmor:
>
> https://www.redhat.com/archives/linux-audit/2014-May/msg00094.html
>
> Is there any progress regarding that issue?
You'll have to ask the AppArmor folks. I gave them a whole block of numbers to
use for their own purposes so that we don't have any problems. If they instead
create malformed SE Linux events, then things will never work right unless
they patch them. I don't plan to carry a patch in the main utility because it
completely violates all audit assumptions.
The main rule is that all audit records of the same type have to have the
exact same fields, in the same order, with the same format or no one can
analyze the events. You have to think of each record as a database table. Each
record is a row, each field is a column.
> I have tried to search for AVC on Debian Testing (auditd 2.4.5), and
> it fails to "grep" me AppArmor related events.
>
> P.S. How do I actually reply to original thread that I did not
> received, since I just subscribed? I though I could maybe find raw
> message in archive https://www.redhat.com/archives/linux-audit/ but
> there aren't (no such message in 2014-May/Jun gz) . Oh how I hate
> using mailing lists so much... /rant.
Just start a new one. Why worry?
-Steve
^ permalink raw reply
* Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log
From: Vincas Dargis @ 2016-04-29 7:03 UTC (permalink / raw)
To: linux-audit
Hi,
There was email about fixing ausearch for AppArmor:
https://www.redhat.com/archives/linux-audit/2014-May/msg00094.html
Is there any progress regarding that issue?
I have tried to search for AVC on Debian Testing (auditd 2.4.5), and
it fails to "grep" me AppArmor related events.
P.S. How do I actually reply to original thread that I did not
received, since I just subscribed? I though I could maybe find raw
message in archive https://www.redhat.com/archives/linux-audit/ but
there aren't (no such message in 2014-May/Jun gz) . Oh how I hate
using mailing lists so much... /rant.
^ 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