On Fri, Sep 8, 2023 at 10:56 AM Pablo Neira Ayuso wrote:
> On Fri, Sep 08, 2023 at 02:22:29AM +0200, Phil Sutter wrote:
> > Perform ruleset modifications and compare the NETFILTER_CFG type
> > notifications emitted by auditd match expectations.
> >
> > Signed-off-by: Phil Sutter
> > ---
> > Calli
next or
the separate audit container ID branch; that's up to him. I've done
this with other big changes in other trees, e.g. SELinux, and it has
worked well to get some extra testing in and keep the patchset "merge
ready" while others outside the subsystem look things over.
--
paul moore
www.paul-moore.com
with other upstream review to get other angles and to
> take some of the load and responsibility off the primary maintainer.
>
> I expect to submit a v5 within a week without having had those questions
> directly answered, but with some ideas of what to check and verify
> before I resubmit. Most of the changes have been sitting in that branch
> for two months, already rebased one kernel version and will need
> updating again.
--
paul moore
www.paul-moore.com
On Thu, Nov 1, 2018 at 2:49 PM Richard Guy Briggs wrote:
> On 2018-10-19 19:17, Paul Moore wrote:
> > On Sun, Aug 5, 2018 at 4:33 AM Richard Guy Briggs
wrote:
> > > Standalone audit records have the timestamp and serial
number generated
> > > on the fly and as s
On Thu, Dec 27, 2018 at 10:34 AM Richard Guy Briggs wrote:
> On 2018-10-31 15:30, Richard Guy Briggs wrote:
> > On 2018-10-19 19:18, Paul Moore wrote:
> > > On Sun, Aug 5, 2018 at 4:33 AM Richard Guy Briggs wrote:
> > > > Add audit container identifier auxili
re is a need for additional container operation auditing (note
well that I did not say audit container id here) then those audit
records can, and should, be generated by the container runtime itself,
similar to what we do with libvirt for virtualization.
--
paul moore
www.paul-moore.com
On Thu, Oct 25, 2018 at 1:38 PM Richard Guy Briggs wrote:
> On 2018-10-25 17:57, Steve Grubb wrote:
> > On Thu, 25 Oct 2018 08:27:32 -0400
> > Richard Guy Briggs wrote:
> >
> > > On 2018-10-25 06:49, Paul Moore wrote:
> > > > On Thu, Oct 25,
On Thu, Oct 25, 2018 at 2:06 AM Steve Grubb wrote:
> On Wed, 24 Oct 2018 20:42:55 -0400
> Richard Guy Briggs wrote:
> > On 2018-10-24 16:55, Paul Moore wrote:
> > > On Wed, Oct 24, 2018 at 11:15 AM Richard Guy Briggs
> > > wrote:
> > > > On 2018-10-19
On October 25, 2018 1:43:16 AM Richard Guy Briggs wrote:
> On 2018-10-24 16:55, Paul Moore wrote:
>> On Wed, Oct 24, 2018 at 11:15 AM Richard Guy Briggs wrote:
>>> On 2018-10-19 19:16, Paul Moore wrote:
>>>> On Sun, Aug 5, 2018 at 4:32 AM Richard Guy Briggs wrote
On Wed, Oct 24, 2018 at 11:15 AM Richard Guy Briggs wrote:
> On 2018-10-19 19:16, Paul Moore wrote:
> > On Sun, Aug 5, 2018 at 4:32 AM Richard Guy Briggs wrote:
> > > Create a new audit record AUDIT_CONTAINER to document the audit
> > > container identifier of
b = audit_log_start(context, GFP_ATOMIC, AUDIT_NETFILTER_PKT);
> if (ab == NULL)
> goto errout;
>
> @@ -104,7 +107,12 @@ static bool audit_ip6(struct audit_buffer *ab, struct
> sk_buff *skb)
>
> audit_log_end(ab);
>
> + net = xt_net(par);
> + audit_log_netns_contid_list(net, context);
> +
> errout:
> + audit_free_context(context);
> +out:
> return XT_CONTINUE;
> }
>
--
paul moore
www.paul-moore.com
unsigned long flags, struct
> task_struct *tsk)
> struct nsproxy *old_ns = tsk->nsproxy;
> struct user_namespace *user_ns = task_cred_xxx(tsk, user_ns);
> struct nsproxy *new_ns;
> + u64 contid = audit_get_contid(tsk);
>
> if (likely(!(flags & (C
merge fallout if/when it happens.
Local contexts are a last resort. If you ever find yourself writing
code that generates a local context, you should first be 100% certain
that the event is not the the result of a process initiated action (in
which case it should take from the task's context).
--
paul moore
www.paul-moore.com
t; audit_log_end(ab);
> return 0;
> }
My previous comments still apply: these audit_log_contid() changes
should be done earlier in the patchset when you first define
audit_log_contid().
--
paul moore
www.paul-moore.com
int audit_log_pid_context(struct audit_context *context, pid_t pid,
> kuid_t auid, kuid_t uid, unsigned int
> sessionid,
> @@ -2024,7 +2047,7 @@ void __audit_inode_child(struct inode *parent,
> int auditsc_get_stamp(struct audit_context *ctx,
>struct timespec64 *t, unsigned int *serial)
> {
> - if (!ctx->in_syscall)
> + if (!ctx->in_syscall && !ctx->local)
> return 0;
> if (!ctx->serial)
> ctx->serial = audit_serial();
--
paul moore
www.paul-moore.com
_CONTAINER_ID here over AUDIT_CONTAINER. If you feel strongly
about keeping it as-is with AUDIT_CONTAINER I suppose I could live
with that, but it is isn't my first choice.
However, I do care about the "op" field in this record. It just
doesn't make any sense; the way you are using it it is more of a
context field than an operations field, and even then why is the
context important from a logging and/or security perspective? Drop it
please.
--
paul moore
www.paul-moore.com
ULL;
> + kmem_cache_free(audit_task_cache, info);
> kfree(key);
> audit_log_lost("out of memory in audit_alloc");
> return -ENOMEM;
> @@ -962,6 +982,12 @@ int audit_alloc(struct task_struct *tsk)
> return 0;
> }
>
> +struct audit_task_info init_struct_audit = {
> + .loginuid = INVALID_UID,
> + .sessionid = AUDIT_SID_UNSET,
> + .ctx = NULL,
> +};
> +
> static inline void audit_free_context(struct audit_context *context)
> {
> audit_free_names(context);
--
paul moore
www.paul-moore.com
Ooops, I hit send prematurely on this :/ My comments below should
stand, but for things like this I usually try to get through the
entire patchset before sending my comments as later patches can affect
my comments on the earlier patches.
On Fri, Oct 19, 2018 at 3:38 PM Paul Moore wrote:
>
task_tgid_nr(task), oldcontid, contid,
> +task_tgid_nr(current), uid,
> +from_kuid(&init_user_ns,
> audit_get_loginuid(current)),
> +tty ? tty_name(tty) : "(none)",
> +audit_get_sessionid(current));
> + audit_put_tty(tty);
> + audit_log_task_context(ab);
> + audit_log_format(ab, " comm=");
> + audit_log_untrustedstring(ab, get_task_comm(comm, current));
> + audit_log_d_path_exe(ab, current->mm);
> + audit_log_format(ab, " res=%d", !rc);
> + audit_log_end(ab);
> + return rc;
> +}
--
paul moore
www.paul-moore.com
etlabel/netlabel_user.c b/net/netlabel/netlabel_user.c
> index 2f328af..4676f5b 100644
> --- a/net/netlabel/netlabel_user.c
> +++ b/net/netlabel/netlabel_user.c
> @@ -101,7 +101,7 @@ struct audit_buffer *netlbl_audit_start_common(int type,
> char *secctx;
> u32 secctx_len;
&g
t, GFP_KERNEL,
> + ab = audit_log_start(audit_context(), GFP_KERNEL,
> AUDIT_CONFIG_CHANGE);
> if (unlikely(!ab))
> return;
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscri
audit_kill_trees(&context->killed_trees);
>
> @@ -2071,8 +2104,8 @@ int audit_set_loginuid(kuid_t loginuid)
> sessionid = (unsigned
> int)atomic_inc_return(&session_id);
> }
>
> - task->sessionid = sessionid;
> - task->loginuid = loginuid;
> + task->audit->sessionid = sessionid;
> + task->audit->loginuid = loginuid;
> out:
> audit_log_set_loginuid(oldloginuid, loginuid, oldsessionid,
> sessionid, rc);
> return rc;
> diff --git a/kernel/fork.c b/kernel/fork.c
> index cd18448..92ab849 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1713,7 +1713,7 @@ static __latent_entropy struct task_struct
> *copy_process(
> p->start_time = ktime_get_ns();
> p->real_start_time = ktime_get_boot_ns();
> p->io_context = NULL;
> - audit_set_context(p, NULL);
> + p->audit = NULL;
> cgroup_fork(p);
> #ifdef CONFIG_NUMA
> p->mempolicy = mpol_dup(p->mempolicy);
> --
> 1.8.3.1
--
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
t; (sig == SIGTERM || sig == SIGHUP ||
> sig == SIGUSR1 || sig == SIGUSR2)) {
> audit_sig_pid = task_tgid_nr(current);
> - if (uid_valid(current->loginuid))
> - audit_sig_uid = current->loginuid;
> +
int return_valid,
> long return_code)
> {
> - struct audit_context *context = tsk->audit_context;
> + struct audit_context *context = tsk->audit.ctx;
>
> if (!context)
> return NUL
hard Guy Briggs
> ---
> include/linux/audit.h | 6 ++
> kernel/auditsc.c | 7 +++
> kernel/fork.c | 2 +-
> 3 files changed, 10 insertions(+), 5 deletions(-)
Merged with some minor fuzz.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send t
deletions(-)
Merged, but there was some fuzz due to the missing 1/5 patch and a
handfull of checkpatch.pl fixes. Please take a look at the commit in
the audit/next branch and if anything looks awry please send a patch
to fix it.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: se
(loginuid)) {
> sessionid = (unsigned int)atomic_inc_return(&session_id);
> - if (unlikely(sessionid == (unsigned int)-1))
> + if (unlikely(sessionid == AUDIT_SID_UNSET))
> sessionid = (unsigned
> int)atomic_inc_return(&session_id);
> }
>
> --
> 1.8.3.1
>
--
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
sk_getsecid(tsk, &audit_sig_sid);
A gentle reminder that you should try to make you patches as
"checkpatch clean" as possible (see scripts/checkpatch.pl). There are
several 80-char warnings, which aren't fatal, but the big no-no is
below:
ERROR: do not use assignment in if con
rity/integrity/integrity_audit.c | 2 +-
> security/lsm_audit.c | 2 +-
> security/selinux/hooks.c | 4 +-
> security/selinux/selinuxfs.c | 6 +--
> security/selinux/ss/services.c | 12 +++---
> 21 files changed, 129 insertions(+), 79 deletion
t; + },
> #endif
> #ifdef CONFIG_PERF_EVENTS
> .perf_event_mutex = __MUTEX_INITIALIZER(init_task.perf_event_mutex),
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f294e4a..b5d8bff 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2068,8 +20
t_syscall_entry(int major, unsigned long a1,
> unsigned long a2,
>unsigned long a3, unsigned long a4)
> {
> struct task_struct *tsk = current;
> - struct audit_context *context = tsk->audit_context;
> + struct audit_context *cont
== (unsigned int)-1))
>> + if (unlikely(sessionid == AUDIT_SID_UNSET))
>> sessionid = (unsigned
>> int)atomic_inc_return(&session_id);
>> }
>>
>> --
>> 1.8.3.1
>>
>> --
>> Linux-audit maili
nk
is good), we should probably access it once, store it in a local
variable, perform the validity check on the local variable, then
commit the local variable to audit_sig_uid. I realize a TOCTOU
problem is unlikely here, but with this new layer of abstraction it
seems that some additional safety might be
gt; starting offset) in decimal, it was very clear what was happenning and
>> seemed worth sharing that debugging tool patch.
>
> If the appropriate device number and full inode number is included I
> don't have any deep problems with the idea. I don't like the bare inode
> number as we have had in the past and may in the future have these inode
> numbers in multiple filesystems so the inode number by itself is not
> unique.
Let's punt on this netfilter record specific patch until we sort out
the general problem of recording namespace/container information in
the audit records.
--
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
log_end(ab);
> @@ -1209,7 +1210,7 @@ struct xt_table_info *xt_replace_table(struct xt_table
> *table,
> AUDIT_NETFILTER_CFGSOLO);
> if (ab) {
> audit_log_task(ab);
> -
; + audit_log_format(ab, " family=%u table=%s
> entries=%u",
> +AF_BRIDGE, repl->name,
> + repl->nentries);
> + audit_log_end(ab);
> +
dea needed to settle a bit more before
> seeing peer review.
>
> I'm also having doubts about two record types.
Richard and I had a discussion about this a week (or two?) ago and I'm
currently of the opinion that two record types are a mistake. I agree
that we need to add the a
ark);
>
> switch (par->family) {
> + case NFPROTO_BRIDGE:
> + switch (eth_hdr(skb)->h_proto) {
> + case htons(ETH_P_IP):
> + fam = audit_ip4(ab, skb) ? NFPROTO_IPV4 : -1;
> + break;
> +
ph),
>> > &_iph);
>>
>> This update is completely pointless.
>
> Its point is to be consistent with audit_ip6() and to prevent further
> time consumed by confusion and head-scratching. I know it is slightly
> slower with an identical result.
Agre
On Fri, Mar 3, 2017 at 8:22 AM, Florian Westphal wrote:
> Paul Moore wrote:
>> On Fri, Mar 3, 2017 at 7:45 AM, Florian Westphal wrote:
>> > Richard Guy Briggs wrote:
>> >> > Perhaps I'm missing something here, but let me ask again, how does
>> >&g
; It can't.
>
> It can if you log it as 0, as I asked in patch 1 review.
>
> (You wouldn't log sk uid of 0 as -1 either, would you?)
I want to see the code able to handle the full range of nfmark values
as well as the unset case; if that means we need to tweak userspace a
bit, ple
On Thu, Mar 2, 2017 at 9:00 PM, Richard Guy Briggs wrote:
> On 2017-03-02 19:16, Paul Moore wrote:
>> On Wed, Mar 1, 2017 at 5:34 PM, Richard Guy Briggs wrote:
>> > On 2017-03-01 17:19, Paul Moore wrote:
>> >> On Wed, Mar 1, 2017 at 11:28 AM, Richard Guy Briggs
&
On Wed, Mar 1, 2017 at 5:34 PM, Richard Guy Briggs wrote:
> On 2017-03-01 17:19, Paul Moore wrote:
>> On Wed, Mar 1, 2017 at 11:28 AM, Richard Guy Briggs wrote:
>> > On 2017-02-28 17:22, Paul Moore wrote:
>> >> On Sun, Feb 26, 2017 at 3:49 PM, Richard Guy Briggs
On Wed, Mar 1, 2017 at 11:28 AM, Richard Guy Briggs wrote:
> On 2017-02-28 17:22, Paul Moore wrote:
>> On Sun, Feb 26, 2017 at 3:49 PM, Richard Guy Briggs wrote:
>> > Eliminate flipping in and out of message fields, dropping fields in the
>> > process.
>> >
mp; skb->dev->type == ARPHRD_ETHER) {
> - audit_log_format(ab, " smac=%pM dmac=%pM macproto=0x%04x",
> -eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest,
> -ntohs(eth_hdr(skb)->h_proto));
> + audit_log_format(ab, "mark=%#x", skb->mark ?: -1);
How do Steve's userspace tools like the unset/-1 value represented
when it is a hex value: -1 or 0x?
--
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
or the configuration complexity, I
think it is safe to say that any users of the NETFILTER_PKT record
already have a sufficiently complex system configuration and the added
complexity here may not be significant; in fact, the existing nfmark
configuration may be helpful in identifying traffic categorie
On Thu, Feb 23, 2017 at 12:35 PM, Richard Guy Briggs wrote:
> On 2017-02-23 12:14, Paul Moore wrote:
>> On Thu, Feb 23, 2017 at 12:13 PM, Richard Guy Briggs wrote:
>> > On 2017-02-23 12:06, Paul Moore wrote:
>> >> On Thu, Feb 23, 2017 at 12:04 PM, Richard Guy Br
On Thu, Feb 23, 2017 at 12:13 PM, Richard Guy Briggs wrote:
> On 2017-02-23 12:06, Paul Moore wrote:
>> On Thu, Feb 23, 2017 at 12:04 PM, Richard Guy Briggs wrote:
>> > On 2017-02-23 11:57, Paul Moore wrote:
>> >> On Thu, Feb 23, 2017 at 10:51 AM, Richard Guy Br
On Thu, Feb 23, 2017 at 12:04 PM, Richard Guy Briggs wrote:
> On 2017-02-23 11:57, Paul Moore wrote:
>> On Thu, Feb 23, 2017 at 10:51 AM, Richard Guy Briggs wrote:
>> > On 2017-02-23 06:20, Florian Westphal wrote:
>> >> Richard Guy Briggs wrote:
>> >>
that handing a NULL
> pointer to "saddr=%pI4" will print "0.0.0.0" rather than "(none)" or "?"
My initial reaction is that if the packet is so badly
truncated/malformed that we don't have a full IP header than we should
just refrain from logging the packet; it's too malformed/garbage to
offer any useful information and the normal packet processing should
result in the packet being discarded anyway.
--
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
On Thu, Feb 16, 2017 at 5:36 PM, Richard Guy Briggs wrote:
> On 2017-02-15 19:32, Paul Moore wrote:
>> On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs wrote:
>> > On 2017-02-13 18:50, Paul Moore wrote:
>> >> On Mon, Feb 13, 2017 at 3:50 PM, Ri
est you can do in some cases is to link the packet to
the socket, and that isn't going to help you.
--
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 majordom
On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs wrote:
> On 2017-02-13 18:50, Paul Moore wrote:
>> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs wrote:
...
>> > helpful action, hook
>>
>> I haven't checked, but do we allow setting of an au
On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs wrote:
> On 2017-02-13 18:50, Paul Moore wrote:
>> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs wrote:
...
>> > useless?smac, dmac, macproto
>>
>> Probably useless in the majority of use case
ess?ipid
Useless.
> helpful proto
> helpful sport, dport
Assuming "proto" means the TCP/UDP/etc. then we should treat the
proto/ports as one block; you can't log the ports without logging
"proto".
> useless?frag
> useless?trun
On Thu, Feb 9, 2017 at 5:56 AM, Pablo Neira Ayuso wrote:
> Hi Paul,
>
> On Wed, Feb 08, 2017 at 06:09:07PM -0500, Paul Moore wrote:
>> On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb wrote:
>> > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
>> >
On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb wrote:
> On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
>> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs wrote:
>> > So while I'm not advocating this is what should be done and I'm trying
>> >
On Wed, Feb 8, 2017 at 7:32 AM, Richard Guy Briggs wrote:
> On 2017-02-07 23:02, Paul Moore wrote:
>> On Tue, Feb 7, 2017 at 4:22 PM, Richard Guy Briggs wrote:
>> > On 2017-02-06 14:41, Paul Moore wrote:
>> >> On Sat, Feb 4, 2017 at 8:25 AM, Steve Grubb wrote:
On Tue, Feb 7, 2017 at 4:22 PM, Richard Guy Briggs wrote:
> On 2017-02-06 14:41, Paul Moore wrote:
>> On Sat, Feb 4, 2017 at 8:25 AM, Steve Grubb wrote:
>> > On Friday, February 3, 2017 6:44:16 PM EST Paul Moore wrote:
>> >> I'm still trying to understan
e
> without a local endpoint?
I'm still waiting on more detailed requirements information from
Steve, but based on what we've heard so far, it seems that ignoring
forwarded traffic is a reasonable thing to do.
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line
On Sat, Feb 4, 2017 at 8:25 AM, Steve Grubb wrote:
> On Friday, February 3, 2017 6:44:16 PM EST Paul Moore wrote:
>> I'm still trying to understand what purpose this record actually
>> serves, and what requirements may exist. In an earlier thread
>> somewhere
interested in data import/export
I think auditing the socket syscalls would provide a much more useful
set of records in the audit log.
Considering that one of the primary motivations for the audit
subsystem is to enable compliance with various security
specifications, let's get the ones we kn
ply 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 netf
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 oth
On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs wrote:
> On 2017-01-18 07:32, Paul Moore wrote:
>> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs wrote:
>> > On 2017-01-17 21:34, Richard Guy Briggs wrote:
>> >> On 2017-01-17 15:17, Paul Moore wrote:
>
On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs wrote:
> On 2017-01-17 21:34, Richard Guy Briggs wrote:
>> On 2017-01-17 15:17, Paul Moore wrote:
>> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs
>> > wrote:
>> > > On 2017-01-17 08:55, Steve G
should be recorded via a dedicated
field, e.g. "secmark", and not use the "subj" field (it isn't a
subject label in the traditional sense).
--
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
iners, or doing a git-bisect of the Debian kernel if
you are comfortable with that sort of thing.
> On 26.04.2016 21:54, Paul Moore wrote:
>>>
>>>
>>> I cannot reproduce it on (one of) previous kernel version:
>>>
>>>lev@debi7:~$ uname -a
>&g
ii iptables-persistent0.5.7+deb7u1
Unfortunately I don't have a Debian system available to test, but have
you tried reproducing this on a more modern kernel?
--
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
69 matches
Mail list logo
