Re: AUDIT_NETFILTER_PKT message format

2017-01-21 Thread Patrick PIGNOL 

Hi all,

I just writen that because I read

"

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.

"

OK you explain me you talk about "Linux audit" sub-system. Cool I didn't 
read it like that ! (I'm waiting for netfilter-dev ml).


Don't tell me that windows is better than linux on that point (see 
ZoneAlarm). I know ZoneAlarm is a Firewall. But if Linux could trace it 
from netfilter you should integrate it in your audit sub system.


I think it should be good to have to know witch application ask for 
send/receive packet on witch protocol and on witch port and for witch IP 
target(from/to) at a given level of verbosity(debug) and how many time 
for a given time-unit (minute-hour).


At this level content of packet is not really useful, I think wire-shark 
is better for that.


Sorry for the noise but it still important for me as a user to can trace 
who have access to an from my computer.


Best regards,

Patrick PIGNOL


Le 21/01/2017 à 18:37, Paul Moore a écrit :

On Sat, Jan 21, 2017 at 6:27 AM, Patrick PIGNOL
 wrote:

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).

The Linux audit subsystem simply logs system events, it does not
enforce security policy.  I suggest you investigate the different
Linux firewall tools and LSMs, e.g. SELinux, as they should help you
accomplish what you describe.



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

2017-01-21 Thread Paul Moore 
On Sat, Jan 21, 2017 at 6:27 AM, Patrick PIGNOL
 wrote:
> 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).

The Linux audit subsystem simply logs system events, it does not
enforce security policy.  I suggest you investigate the different
Linux firewall tools and LSMs, e.g. SELinux, as they should help you
accomplish what you describe.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH nf] netfilter: nf_tables: report error if stateful obj's name is truncated

2017-01-21 Thread Patrick PIGNOL 


Le 19/01/2017 à 15:41, Liping Zhang a écrit :

The nft table name's size is limited at this place:
static const struct nla_policy nft_table_policy[NFTA_TABLE_MAX + 1] = {
 [NFTA_TABLE_NAME] = { .type = NLA_STRING,
.len =
NFT_TABLE_MAXNAMELEN - 1 },

If NFTA_CHAIN_TABLE's size exceeded 31, nf_tables_table_lookup will
fail eventually.


Why ? :


typedef unsigned short __u16; // minimum MaxValue = 65535

 /*
*  <--- NLA_HDRLEN --> <-- NLA_ALIGN(payload)-->
* +-+- - -+- - - - - - - - - -+- - -+
* |Header   | Pad | Payload | Pad |
* |   (struct nlattr)   | ing || ing |
* +-+- - -+- - - - - - - - - -+- - -+
*  <-- nlattr->nla_len --> // Payload minimum 
MaxValue = 65535 - (at least)32 = 65503

*/

struct nlattr {
__u16   nla_len;
__u16   nla_type;
};

#define NFT_SET_MAXNAMELEN  32  // <- Why 32 ? Why not 65535 or 65503
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AUDIT_NETFILTER_PKT message format

2017-01-21 Thread Patrick PIGNOL 

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  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?



--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html