netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:28:43 -0700	[thread overview]
Message-ID: <lrk6or$unu$2@ger.gmane.org> (raw)
In-Reply-To: r3nvbqajovk.fsf@perdido.sfo.corp.google.com

Peter Moody wrote:

> 
> On Sat, Aug 02 2014 at 18:49, Alex Elsayed wrote:
> 
>> Well, the simple answer is "define a policy that allows everything except
>> network operations, and denies those" - this is reasonably simple if you
>> use ACL groups because you can set the 'default policy' with acl group 0.
> 
> I'm not understanding. I don't want to deny network operations, I just
> want to be able to associate the operation with the 'offending' process.
> 
>> Yeah, there are flavors of Tomoyo (out-of-tree) that can be stacked, and
>> there's the ongoing effort from Casey Schaufler to enable stacking more
>> generally.
> 
> Yeah, Casey was the one who suggested that I re-write this as an LSM. I
> think he saw the monitoring that I'm trying to do (as opposed to
> standard LSM deny/permit) as a good candidate for stacking.
> 
> 
>> CaitSith is rather different, in that rather than having domain be the
>> primary key things operate off of, the action is the central piece. So
>> while Tomoyo's policy syntax is
>>
>> DOMAIN
>>     POLICY ACTION CONDITION
>>
>> CaitSith's is
>>
>> ACTION [QUALIFIER]
>>     PRIORITY POLICY CONDITION [CONDITION...]
> 
> Interesting. It sounds like it's still primary designed to deny/permit
> actions (based on some policy) and I'm really just looking to monitor.

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.

In the header of a CaitSith policy, you specify resource limits for audit 
logs in the format

quota audit[$audit_index] allowed=$max_logs_for_allowed_request 
unmatched=$max_logs_for_unmatched_request 
denied=$max_logs_for_denied_request

(sans the linewrapping)

Now, by default _everything_ logs into audit index zero, but you can have 
multiple audit logs, and you can specify which one an action logs into. The 
result:

# Don't pollute the logs
quota audit[0] allowed=0 unmatched=0 denied=0

# Allow a one-million-item backlog of events that don't
# have an explicit policy allow/deny set on this unusual audit field
quota audit[1] allowed=0 unmatched=1000000 denied=0

# Whenever someone tries to bind an AF_UNIX socket...
0 acl unix_stream_bind
    # ...log that sucker.
    audit 1


  reply	other threads:[~2014-08-03  2:28 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 [this message]
2014-08-03  2:38               ` Peter Moody
2014-08-03  2:41                 ` Alex Elsayed
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='lrk6or$unu$2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).