From: Alex Elsayed <eternaleye@gmail.com>
To: linux-security-module@vger.kernel.org
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH v2 0/2] RFC, aiding pid/network correlation
Date: Sat, 02 Aug 2014 19:41:15 -0700 [thread overview]
Message-ID: <lrk7gb$unu$4@ger.gmane.org> (raw)
In-Reply-To: r3nr40yjo1e.fsf@perdido.sfo.corp.google.com
Peter Moody wrote:
>
> On Sat, Aug 02 2014 at 19:28, Alex Elsayed wrote:
>
>> Oh, I see now. Okay, that's actually considerably simpler - I just had
>> somehow gotten it fixated into my mind that the info would be used to
>> decide on allow/deny actions.
>>
>> The trick to do what you want is the 'audit' support in both -
>> here I'll use CaitSith as an example since the syntax is nicer.
>
> Do these audit logs end up with the audit subsystem? My experience with
> the audit subsystem is that performance takes a big hit when you start
> sending thousands (or even hundreds) of audit messages per second.
No, they go straight to /proc/caitsith/audit and wind up looking like this:
#2012/04/08 05:03:03# global-pid=3720 result=allowed priority=100 / read
path="/tmp/file1" task.pid=3720 task.ppid=3653 task.uid=0 task.gid=0
task.euid=0 task.egid=0 task.suid=0 task.sgid=0 task.fsuid=0 task.fsgid=0
task.type!=execute_handler task.exe="/bin/cat" task.domain="/usr/sbin/sshd"
path.uid=0 path.gid=0 path.ino=2113451 path.major=8 path.minor=1
path.perm=0644 path.type=file path.fsmagic=0xEF53 path.parent.uid=0
path.parent.gid=0 path.parent.ino=2097153 path.parent.major=8
path.parent.minor=1 path.parent.perm=01777 path.parent.type=directory
path.parent.fsmagic=0xEF53
>> In the header of a CaitSith policy, you specify resource limits for audit
>> logs in the format
>
> I will definitely check out caitsith though. I think I saw Tetsuo talk
> about it at LSS in San Diego a few years ago.
next prev parent reply other threads:[~2014-08-03 2:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-01 1:21 [PATCH v2 0/2] RFC, aiding pid/network correlation Peter Moody
2014-08-01 1:21 ` [PATCH 1/2] security: create task_post_create callback Peter Moody
2014-08-01 1:21 ` [PATCH 2/2] security: Hone LSM Peter Moody
2014-08-01 12:16 ` [PATCH v2 0/2] RFC, aiding pid/network correlation Samir Bellabes
2014-08-01 17:22 ` Peter Moody
2014-08-02 0:30 ` Samir Bellabes
2014-08-02 15:05 ` Peter Moody
2014-08-02 4:55 ` Alex Elsayed
2014-08-03 1:34 ` Peter Moody
2014-08-03 1:49 ` Alex Elsayed
2014-08-03 2:19 ` Peter Moody
2014-08-03 2:28 ` Alex Elsayed
2014-08-03 2:38 ` Peter Moody
2014-08-03 2:41 ` Alex Elsayed [this message]
2014-08-03 2:47 ` Alex Elsayed
2014-08-03 3:14 ` Peter Moody
2014-08-03 3:41 ` Alex Elsayed
2014-08-03 21:57 ` Peter Moody
2014-08-03 22:18 ` Alex Elsayed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='lrk7gb$unu$4@ger.gmane.org' \
--to=eternaleye@gmail.com \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.