From: Patrick PIGNOL <patrick.pignol@gmail.com>
To: Paul Moore <paul@paul-moore.com>, Steve Grubb <sgrubb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
Paul Moore <pmoore@redhat.com>,
Linux-Audit Mailing List <linux-audit@redhat.com>,
Netfilter Developer Mailing List
<netfilter-devel@vger.kernel.org>,
Thomas Graf <tgraf@infradead.org>
Subject: Re: AUDIT_NETFILTER_PKT message format
Date: Sat, 21 Jan 2017 12:27:39 +0100 [thread overview]
Message-ID: <e14df9b0-e6ea-c60f-f580-40b10af2392f@gmail.com> (raw)
In-Reply-To: <CAHC9VhT8QQ2inKgJ_ZAeiEOvmnjv-0AbHjrRf-LGfUT+WMFUeQ@mail.gmail.com>
Hi all,
I disagree !
Many people in the world would like to allow an software A to go to
internet through OUTPUT TCP port 80 but disallow software B to go to the
internet through this same OUTPUT TCP port 80. Don't you know about
viruses on linux ? Viruses ALWAYS use HTTP/HTTPS ports to get payloads
on internet and OUTPUT TCP port 443 COULD NOT be CLOSED for ALL SOFTWARE
if you want to access internet services (via internet browsers for example).
And we cannot know every dangerous IP in the world. Even because there
are new one every time in the world. There could be a not dangerous
server that became dangerous one because it became a hacked server.
So it's an EXCELLENT idea to make Software socket/PID accessible from
packet netfilter API. That could prevent some malware to access opened
standard ports and give to the users a way to make better protection
with closest control on which software ave right to get information from
the internet.
BE USER FRIENDLY PLEASE !!!!
Best regards,
Patrick PIGNOL
Le 20/01/2017 à 21:37, Paul Moore a écrit :
> On Fri, Jan 20, 2017 at 9:49 AM, Steve Grubb <sgrubb@redhat.com> wrote:
>> On Wednesday, January 18, 2017 6:35:29 PM EST Paul Moore wrote:
>>> At this point I think it would be good to hear what requirements exist
>>> for per-packet auditing. Steve, are there any current Common Criteria
>>> (or other) requirements that impact per-packet auditing?
>> I don't think you want to flood your logs. That is not helpful. It asks for the
>> ability to detect information flow. Typically you want to know source and
>> destination, protocol, where on the system its coming from or going to, pid if
>> possible and the subject information if available. I know that you can be
>> acting as a proxy and forwarding outside packets into a network. That is not
>> the typical case CC is concerned about. Its more about what the user is doing.
> Determining the pid/subj of a packet is notoriously
> difficult/impossible in netfilter so let's drop that; with proper
> policy/rules you should be able to match proto/port with a given
> process so this shouldn't be that critical. The source/destination
> addresses and proto/port (assuming IP) should be easy enough.
>
> All right, now that we've got the "must" items down, are their any
> "should" items we want?
>
next prev parent reply other threads:[~2017-01-21 11:27 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-17 5:25 AUDIT_NETFILTER_PKT message format Richard Guy Briggs
2017-01-17 13:55 ` Steve Grubb
2017-01-17 16:12 ` Richard Guy Briggs
2017-01-17 16:29 ` Richard Guy Briggs
2017-01-17 18:35 ` Steve Grubb
2017-01-17 20:17 ` Paul Moore
2017-01-18 2:34 ` Richard Guy Briggs
2017-01-18 5:39 ` Richard Guy Briggs
2017-01-18 12:32 ` Paul Moore
2017-01-18 14:52 ` Steve Grubb
2017-01-18 15:15 ` Richard Guy Briggs
2017-01-18 23:35 ` Paul Moore
2017-01-20 14:49 ` Steve Grubb
2017-01-20 20:37 ` Paul Moore
2017-01-21 11:27 ` Patrick PIGNOL [this message]
2017-01-21 17:37 ` Paul Moore
2017-01-21 19:12 ` Patrick PIGNOL
2017-01-23 4:49 ` Richard Guy Briggs
2017-02-07 20:52 ` Richard Guy Briggs
2017-02-08 3:56 ` Paul Moore
2017-02-08 16:30 ` Steve Grubb
2017-02-08 23:09 ` Paul Moore
2017-02-09 10:56 ` Pablo Neira Ayuso
2017-02-09 16:31 ` Paul Moore
2017-02-09 23:49 ` Richard Guy Briggs
2017-02-10 0:09 ` Steve Grubb
2017-02-10 1:12 ` Richard Guy Briggs
2017-02-10 22:39 ` Steve Grubb
2017-02-10 22:54 ` Richard Guy Briggs
2017-02-13 17:57 ` Steve Grubb
2017-02-13 20:50 ` Richard Guy Briggs
2017-02-13 23:50 ` Paul Moore
2017-02-14 0:24 ` Richard Guy Briggs
2017-02-14 21:06 ` Paul Moore
2017-02-16 22:41 ` Richard Guy Briggs
2017-02-16 0:32 ` Paul Moore
2017-02-16 22:36 ` Richard Guy Briggs
2017-02-17 1:57 ` Paul Moore
2017-02-17 2:24 ` Richard Guy Briggs
2017-02-17 23:04 ` Paul Moore
2017-02-26 19:09 ` Richard Guy Briggs
2017-02-14 21:31 ` Steve Grubb
2017-02-16 21:24 ` Richard Guy Briggs
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=e14df9b0-e6ea-c60f-f580-40b10af2392f@gmail.com \
--to=patrick.pignol@gmail.com \
--cc=linux-audit@redhat.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=pmoore@redhat.com \
--cc=rgb@redhat.com \
--cc=sgrubb@redhat.com \
--cc=tgraf@infradead.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.