linux-kernel - Re: How to find origin PID of a sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <877i9qu9cw.fsf@burp.tkv.asdf.org>
Date:	Fri, 05 Sep 2008 14:21:03 +0300
From:	Markku Savela <msa@...h.iki.fi>
To:	linux-kernel@...r.kernel.org
Subject: Re: How to find origin PID of a sk_buff in iptables match?

> Also, I noticed that in my match code in OUTPUT chain, the current
> task seemed to the originator I want (ping test). However, I'm not
> quite sure whether this is always true?

Well, nobody answered.

Anyway, as suspected with TCP connections it seems that current->pid
produces 0 very often after the first initial packet (SYN). I take
this to mean, that the TCP engine is being executed on some interrupt
context?

Now I'm wondering how SELINUX manages to get the secmark right, as the
code in iptables seems to eventually need the current task context?
Something tricky being made using the SECMARK and CONNSECMARK? It
seems to trust, that at least the first packet has the current task
context properly set and the remaining packets of the connection don't
need current task?

I guess I have to dug deeper in this (emulate what SELINUX does). Or
can someone point to a tutorial description on how to reliably
associate each outgoing packet with some originating task context?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/