Random stuff collected from #netfilter irc channel (on OPN aka Freenode) related to matching packets by pid, owner process and whatnot:

All times in EET timezone

--- Day changed Sat May 07 2005
04:33 -!- amd64lover [~miknix@bl4-161-85.dsl.telepac.pt] has joined #netfilter
04:33 < amd64lover> hi there
04:34 < amd64lover> how can i match packets according their destination program?
04:34 < amd64lover> any idea?
04:35 < kaber> the is the owner-socket-lookup patch .. which is kind of a hack
04:35 < kaber> but it works 
04:36 < amd64lover> stable?
04:36 < kaber> yes, but has conceptual problems
04:36 < kaber> but works in most cases anyway
04:38 < amd64lover> now i have iptables allowing international packets during night and blocking during day. but i only want to block packets from/to mldonkey p2p during day, not whole packets
04:39 < kaber> block packets, not whole packets?
04:39 < kaber> ah, you mean not all packets? :)
04:39 < amd64lover> yes
04:39 < amd64lover> sorry
04:40 < amd64lover> got the ideia
04:40 < amd64lover> ?
04:40 < kaber> yes
04:40 < kaber> should work with the patch
04:40 < kaber> the process matching .. time matching has to be done otherwise of course
04:41 < amd64lover> what about marking packets related to the mldonkey listening port?
04:42 < kaber> how are they related?
04:42 < amd64lover> when some packet arrives
04:42 < kaber> same way as for established connection
04:42 < kaber> -A INPUT -m owner --cmd-owner mldonkey
04:43 < amd64lover> yes.. but not using this patch
04:43 < amd64lover> my idea was...
04:43 < kaber> does't work without the patch
04:44 < kaber> ok fixed ports work .. but I think it dynamically opens ports
04:45 < kaber> I suggest to delete it immediately anyway, edonkey is a piece of crap and cancer for the network
04:45 < amd64lover> why?
04:46 < amd64lover> better speed than torrents
04:46 < kaber> it overloads the network by opening thousands of connections and even harmless people never using this crap get hammered because their dynamiccaly assigned IP is noted somewhere as edonkey user
04:47 < kaber> on my last dsl line I got average 50 requests for edonkey crap per second
04:47 < amd64lover> what do you sugest?
04:48 < kaber> use the match, it will work .. I just don't like edonkey :)
04:48 -!- sIm_kp [~hah@147.69.117.183] has left #netfilter []
04:49 < amd64lover> when some connecion request is received on listening port of mldonkey (it is always the same port), the mldonkey creates a new connection with some new random port. right? after that iptables knows that this connection is related, and is always accepted. with conntrack, i know witch connections are related to mldonkey..
04:50 < amd64lover> what do you think?
04:50 < kaber> no, conntrack doesn't know anything about random ports and edonkey can't transder portnumbers when accepting
04:50 < kaber> it uses dynamically assigned port-numbers
04:51 < amd64lover> yes..
04:51 < kaber> so use the patch
04:52 < amd64lover> but i only have two rules to keep mldonkey working.. the first one is to accept incoming requests for the mldonkey port and the other one for accepting related connections
04:53 < amd64lover> so iptables knows about the related connections, wich are the ones i want to reject
04:54 < amd64lover> but never mind.. the patch looks great for me
04:54 -!- kaber [~kaber@2001:5c0:8fff:fffe:0:0:0:8d3] has quit ["RTFM"]
05:05 -!- amd64lover [~miknix@bl4-161-85.dsl.telepac.pt] has quit ["using sirc version 2.211+KSIRC/1.3.11"]


--- Day changed Sat Aug 13 2005
07:28 < Swedish_Chef> is there any way to block connections to/from a specific application, rather than by ports?
17:16 < Gandalf_> Swedish_Chef: look at the owner match
17:22 -!- lilo [i=levin@freenode/staff/pdpc.levin] has quit ["brb"]
17:33 < jengelh> the problem is that -m owner matches the owner of the socket not the owner of the process
17:33 < jengelh> so privileged apps that bind to <1024 ports always belong to root
17:34 < Swedish_Chef> what about --cmd-owner?
17:36 -!- lilo [i=levin@freenode/staff/pdpc.levin] has joined #netfilter
17:36 < jengelh> [!] --cmd-owner name       Match local command name
17:36 < jengelh> the name is misleading
17:36 < Gandalf_> patches are welcome
17:37 < jengelh> heh
17:37 < jengelh> the problem is not the patch but the kernel
17:37 < jengelh> just read the SMP warning in owner.c
17:38 < LaF0rge> patches probably useless anyway, now that everything but uid/git matching will be removed
17:38 < jengelh> why that
17:38 < jengelh> . o O ( gid or GIT ;-) )
17:39 < jengelh> could not we take a spinlock in the SMP-unsafe paths?
17:41 < LaF0rge> jengelh: tasklist locking in the core kernel changes
17:42 < LaF0rge> jengelh: we have to remove all that crappy matching
17:42 < jengelh> you mean "is changing" [in the current development] ?
17:42 < LaF0rge> yes, is changing
17:42 < jengelh> you can speak .de to me ;)
17:44 < LaF0rge> you won't hear me speaking ;)


--- Day changed Mon Nov 21 2005
17:23 < xkr47> but but! what happened to ipt_owner.c!!
17:24 < xkr47> I c..
17:24 < xkr47> ownercmd was removed in 2.6.14 :(
17:24  * xkr47 wonders if somebody did a mistake or if it was doomed bad
17:25 < xkr47> s/doomed/classified/
17:26 < Hidden> http://tinyurl.com/eyylw
17:27 < xkr47> thanks and :(
17:28 < xkr47> unfixable.. now how is that possible in linux :P
17:29 < xkr47> my firewall depends on it :(
17:30 < xkr47> seems like I have to stick with 2.6.11 (or 2.6.13 if I decide to upgrade) then..
17:31 < xkr47> gub
17:31 < xkr47> :(


--- Day changed Mon Dec 19 2005
14:33 < Zap-W> about OWNER match extension
14:34 < Zap-W> says , command name is no longer supported
14:34 < Zap-W> it can't detect programs based on their process name anymore
14:34 < Zap-W> match
14:35 < Zap-W> why was it removed
14:42 -!- crash[bg] [n=crash@85.187.187.2] has quit [Read error: 104 (Connection reset by peer)]
14:44 < Hidden> Zap-W: http://tinyurl.com/7crsj
14:44 < Hidden> Zap-W: one cannot access the task structure from softirq context because of locking issues
14:44 -!- crash[bg] [n=crash@85.187.187.2] has joined #Netfilter


--- Day changed Tue Dec 27 2005
17:35 -!- Zap-W [i=zapw@80.178.86.145.adsl.012.net.il] has joined #netfilter
17:35 < Zap-W> say
17:35 < Zap-W> i need an alternative to OWNER "match command name" that was removed
17:39 < Zap-W> Wooho
17:40 < Regit> nufw : http://www.nufw.org
17:47 < Zap-W> dosent this slow things alot?

.. nufw disappeared sometimes late 2011, but is archived here: https://web.archive.org/web/20110930044425/http://www.nufw.org/


--- Day changed Mon Jan 07 2008
20080107_1356-!- paravoid [n=paravoid@147.102.3.90] has joined #netfilter
20080107_1356< paravoid> hi
20080107_1356< paravoid> is there a way to do the equivalent of "-j RETURN" from userland/NFQUEUE?
20080107_1357< paravoid> i.e. pass the packet to userland and instead of just accepting or dropping it, have to option to continue traversing the kernel rules
20080107_1358-!- Visual_E [n=easy@unaffiliated/visuale/x-000000001] has quit ["Leaving"]
20080107_1359< VictorJ> paravoid: I don't think there is
20080107_1359< VictorJ> I would love that too
20080107_1359< jengelh> in INPUT or OUTPUT?
20080107_1359< paravoid> input
20080107_1400< jengelh> that won't fly programmatically
20080107_1400< paravoid> why not?
20080107_1400< paravoid> not really familiar with the internals of netfilter, obviously
20080107_1400< jengelh> because when -j NFQUEUE is reached, the current pointer into the firewall rules is dropped
20080107_1400< jengelh> we would not know where to inject the packet again
20080107_1401< paravoid> well, that means that it's not possible atm
20080107_1401< jengelh> yeah, atm.
20080107_1401< paravoid> not that it won't be possible with the current architecture
20080107_1401< paravoid> am I wrong?
20080107_1401< jengelh> you would have to store the stack for each skb that traverses a table
20080107_1402< jengelh> and what if the ruleset changes while the packet is 'visiting' userspace?
20080107_1402< paravoid> hrm
20080107_1403< paravoid> it's not the reason I was asking but I'm curious,
20080107_1403< paravoid> is there a way to mangle packets in userspace
20080107_1403< paravoid> either in INPUT or OUTPUT?
20080107_1404< jengelh> that's what userspace is for ;p
20080107_1405< paravoid> ?
20080107_1415< jengelh> yes
20080107_1415< jengelh> you can modify the packet in userspace, then pass it back
20080107_1416< paravoid> ah, right. forgot about that
20080107_1643< paravoid> jengelh: any idea if I can set the verdict on packets out of order?
20080107_1643< paravoid> in an nfqueue application I mean
20080107_1643< jengelh> yes, you do that from userspace
20080107_1643< jengelh> if you want to drop a packet, just don't return it to userspace
20080107_1643< jengelh> er
20080107_1643< jengelh> kspace
20080107_1643< paravoid> I mean, set the verdict on packet id 4, then to 2, then to 6 etc.
20080107_1643< jengelh> what is the packet id?
20080107_1644< paravoid> nfq_set_verdict(qh, id, verdict, ...)
20080107_1644< paravoid> IOW, is there a way to ask the kernel to queue more packets
20080107_1644< paravoid> but return the verdict at a later point?
20080107_1645< jengelh> don't you have to call nfq_submit or so?
20080107_1645< paravoid> get 10 packets then respond for each them out of order
20080107_1645< jengelh> i dunno libnetfilter too much
20080107_1645< jengelh> usually yes, you can respond out of order
20080107_1645< paravoid> I'm using libnetfilter-queue and I'm not sure of the abstraction specifics
20080107_1645< jengelh> just keep their buffers around
20080107_1645< jengelh> what's the #include line for nfq?
20080107_1647< paravoid> <libnetfilter_queue/libnetfilter_queue.h>
20080107_1647< paravoid> basically I've done something really nasty
20080107_1647< paravoid> and evil
20080107_1647< jengelh> haha
20080107_1647< paravoid> but works for me(tm)
20080107_1647< paravoid> I'm checking for listening sockets
20080107_1647< paravoid> in /proc
20080107_1647< paravoid> basically the equivalent of netstat -nlp
20080107_1648< paravoid> and tell my application to accept everything intended for specific processes
20080107_1648< paravoid> i.e. the equivalent of -m owner but for incoming packets
20080107_1649< paravoid> really useful when the protocol is complex enough that the connection trackers fail
20080107_1649< paravoid> (in my case, H.323)
20080107_1649< paravoid> it's totally racy
20080107_1649< paravoid> but I don't care
20080107_1649< jengelh> where would it be racy
20080107_1650< paravoid> the socket may not be open yet
20080107_1650< paravoid> or something, not sure :)
20080107_1650< jengelh> you mean in listening state.
20080107_1650< paravoid> yes, of course
20080107_1650< jengelh> well then you just drop the packet
20080107_1651< paravoid> yep
20080107_1651< paravoid> big deal :)
20080107_1651< jengelh> that's not a race
20080107_1651< paravoid> either it's important enough that the upper layers will do a retransmit
20080107_1651< paravoid> l4 or l7, doesn't matter
20080107_1651< paravoid> or it's rtp and it's a subsecond of audio
20080107_1652-!- Brownout [n=brownout@pdpc/supporter/base/brownout] has joined #netfilter
20080107_1654< jengelh> hm
20080107_1654< jengelh> the problem is that set_verdict implies transmit
20080107_1654< jengelh> what was it that you needed?
20080107_1655< paravoid> doesn't matter much
20080107_1655< paravoid> I was wondering if I could spawn multiple threads
20080107_1655< paravoid> to handle multiple packets concurrently
20080107_1655< acidfu> why would you want to do that
20080107_1656< paravoid> because determining the verdict takes time
20080107_1656< acidfu> and sechduling thread doesnt take time ?
20080107_1656< jengelh> acidfu: no :)
20080107_1656< jengelh> think SMP
20080107_1656< paravoid> yep, I'm running this on dual quad-core xeon
20080107_1656< acidfu> in userspace... :P
20080107_1657< jengelh> haha
20080107_1657< acidfu> the time you wast is there dude
20080107_1657< acidfu> not in determining the verdict
20080107_1657< jengelh> each thread could be in the kernel asynchronously
20080107_1657< paravoid> anyway, I've went to an alternate design
20080107_1657< paravoid> I'm updating a cache on a separate thread
20080107_1657< paravoid> and then just do cache lookups on incoming packets
20080107_1658< paravoid> and it's quite fast
20080107_1658< Regit> paravoid: http://www.synack.fr/project/cn_net/cn_net.html
20080107_1658< Regit> looks like your own system
20080107_1659< Regit> same target
20080107_1659< jengelh> i never got the idea of what CONFIG_CONNECTOR is good for
20080107_1659< paravoid> not exactly
20080107_1700< paravoid> interesting though
20080107_1701< paravoid> anyway, I'm quite happy with the way it is now
20080107_1701< paravoid> but was wondering for alternative designs
20080107_1701< paravoid> if I could do things differently etc.
20080107_1702< jengelh> you could write a kernel module
20080107_1702< paravoid> that does what?
20080107_1702< jengelh> that does whatever you are trying to achieve in userspace
20080107_1702< paravoid> Patrick McHardy tried
20080107_1702< paravoid> and failed
20080107_1702< jengelh> haha
20080107_1702< paravoid> it was called owner-socketlookup
20080107_1703< paravoid> we had a brief exchange of emails
20080107_1703< paravoid> "No, the patch was broken, the socket can't be looked up on the input path without races and there was some strong reluctance against adding the required exports."
20080107_1703< paravoid> "The netfilter socket hooks are a replacement for this patch, but I haven't touched that patch in quite a while and it won't apply to current  kernels."
20080107_1703< paravoid> that was on 23/11/2006
20080107_1703< jengelh> well
20080107_1703< jengelh> if you are "just" doing netstat, that can be done with exports yeah :/
20080107_1703< jengelh> or a kernel thread that mimics userspace
20080107_1704< paravoid> I don't care that much about the performance penalties
20080107_1704< paravoid> I'd like to avoid being hammered by a DoS
20080107_1704< paravoid> but besides that, I don't intend running hundreds of h323 calls
20080107_1706< sam_synack> jengelh: CONFIG_CONNECTOR is a tool for communication between userspace and kernelspace, it's based on netlink
20080107_1706< sam_synack> Regit: hi guy
20080107_1706< jengelh> that's too vague to be useful :)
20080107_1706< sam_synack> jengelh: how ?
20080107_1707< jengelh> what does it do that netlink does not?
20080107_1707< sam_synack> jengelh: you can send message, so data between the kernel and userspace
20080107_1707< jengelh> that sounds like netlink.
20080107_1707< sam_synack> jengelh: it's a API, so it's more simple to use that direct netlink API
20080107_1708< sam_synack> jengelh: construction of the message (the skbuff) is more simple
20080107_1708< sam_synack> jengelh: construction of the message (the skbuff) which is about to be sent to the userspace, is more simple
20080107_1708< jengelh> ok
20080107_1708< sam_synack> *but* now, you should consider to forget about connector, and use the libnl API
20080107_1709< sam_synack> http://people.suug.ch/~tgr/libnl/
20080107_1710< sam_synack> it have a Generic family (quite similar to connector) http://people.suug.ch/~tgr/libnl/doc-1.0-pre7/group__genl.html
20080107_1711< Regit> sam_synack: hi ;)
20080107_1711< sam_synack> and so, there is a lib in the userspace, thing you won't have with the connector, as you have to deal with netlink socket in userspace if you use the linux kernel connector
20080107_1711< sam_synack> btw, I'm behind the cn_net project, if you have questions 
20080107_1713< sam_synack> paravoid: cn_net is perfect in your case 'when the conntrack fail (because it doesn't exist for example)'
20080107_1713< jengelh> the conntrack watcher :)
20080107_1714< sam_synack> because, cn_net dectects the ports which are changing theirs states to LISTEN. And guess is if someone is listening, maybe it's for something which is about to income..
20080107_1715< sam_synack> jengelh: not exactly, see last line


--- Day changed Fri Jan 25 2008
20080125_1401< Hidden> jengelh: I was thinking about the tproxy vs DNAT stuff
20080125_1401< jengelh> oh?
20080125_1401< jengelh> ah.
20080125_1401< Hidden> jengelh: I think you're right that there's no point in using it with DNAT
20080125_1402< Hidden> but I still don't like it cause it's a hack
20080125_1402< Hidden> unfortunately the other option (reintroducing the tproxy table) is even worse
20080125_1402< jengelh> how would the tproxy table deal with it?
20080125_1403< Hidden> it'd be traversed after nat
20080125_1403< Hidden> on PREROUTING
20080125_1403< Hidden> so it'd see the final (nat-ted) address
20080125_1403< jengelh> well, so you could just use -m socket in nat
20080125_1406< Hidden> well, theoretically yes
20080125_1408< Hidden> let's try to get SNAT working first
20080125_1409< jengelh> nat-postrouting is run after filter even
20080125_1409< jengelh> the whole table concept needs a rework
20080125_1412< Hidden> yes, but you can't do that without breaking rulesets...
20080125_1413< Hidden> jengelh: don't you happen to have some time integrating this SNAT-workaround into xt_socket? :)
20080125_1413< jengelh> heh
20080125_1413< jengelh> I would
20080125_1413< Hidden> I have a tproxy tree which seems to be compiling on davem's net-2.6.25
20080125_1414< Hidden> but I have no time working on this at the moment
20080125_1414< Hidden> nor to merge it with your xt_socket (renamed xt_owner)
20080125_1414< jengelh> I could need some help in getting the rename done NOW
20080125_1415< jengelh> e.g. voting for my standpoint to do the rename now rather than later
20080125_1415< Hidden> it's fine with me, anyway
20080125_1415< Hidden> and as far as I could see it was OK with Patrick
20080125_1416< jengelh> it was ok with Laszlo
20080125_1416< jengelh> Patrick merged the xt_owner UID/GID range one instead of the two xt_socket block
20080125_1417< jengelh> Citing,
20080125_1417< jengelh> "I'm going to apply the first patch you sent.                                    
20080125_1417< jengelh> "
20080125_1417< Hidden> well, did he have any concerns with the second one?
20080125_1417< jengelh> there were two/three things
20080125_1417< jengelh> [1] add uid range support to xt_owner
20080125_1417< jengelh> [2] xt_owner->xt_socket, and uid range support for xt_socket
20080125_1419< Hidden> yep, and he merged only the first one, right?
20080125_1419< jengelh> http://marc.info/?l=netfilter-devel&m=120117427820067&w=2
20080125_1420< jengelh> by first one, I suppose he meant "I keep xt_owner"
20080125_1420< jengelh> though it might also mean "I merged xt_socket, but not the uidrange"
20080125_1420< jengelh> given that marc.info posting, I suppose it was uidrange for xt_owner which was merged
20080125_1423< Hidden> yes
20080125_1424< Hidden> but still, in this case we'd have to integrate your xt_owner->xt_socket rename patch into the tproxy tree
20080125_1424< jengelh> and it would be another flag day
20080125_1429< Hidden> http://people.netfilter.org/hidden/tproxy/tproxy4_2.6.25_200801251326.tar.bz2
20080125_1429< Hidden> this is my latest set of patches
20080125_1429< Hidden> on top of a7f92e3b13a5e3db64383c503f2249dc74b41bd6
20080125_1430< jengelh> all you need is using the saddr, no?
20080125_1430< jengelh> the ctorigsrcaddr that is
20080125_1430< Hidden> yes
20080125_1431< Hidden> if conntrack's enabled and the ctrack entry is SNAT-ted
20080125_1431< jengelh> yeah that's like 4 lines
20080125_1431< Hidden> exactly
20080125_1431< Hidden> and there was something else missing which I can't remember at the moment
20080125_1431< Hidden> oh, yeah: the netfilter route_me_harder() thing
20080125_1431< jengelh> for xt_socket!?
20080125_1432< Hidden> no, for tproxy in general
20080125_1432< jengelh> i dunno what route_me_harder exactly does
20080125_1432< jengelh> would have to look at source
20080125_1432< Hidden> let me have a look at it
20080125_1433< jengelh> seems to adjust the route to the iph fields, nothing more
20080125_1434< Hidden> I'll forward the mail with the description of the problem
20080125_1434< Hidden> although it was on the tproxy list
20080125_1435< Hidden> so the problem is that those route lookups in there don't check the skb mark
20080125_1435< Hidden> so generally they don't work with policy routing
20080125_1435< Hidden> and tproxy uses this
20080125_1435< Hidden> so if you -j MARK something on output
20080125_1436< Hidden> which was sent from a socket whith a foreign address
20080125_1436< jengelh> you lost me
20080125_1436< jengelh> why am I even looking at ip_route_me_harder?
20080125_1437< Hidden> that's the only remaining problem with tproxy
20080125_1437< Hidden> but I'll try to fix it
20080125_1437< Hidden> so don't worry about it
20080125_1437< jengelh> hm...
20080125_1437< jengelh> >     With MARK, only local IP could have packets going out of the box.         
20080125_1437< Hidden> yes
20080125_1437< jengelh> how so?
20080125_1438< Hidden> and that's because of it actually reroutes the packets if you mark them on OUTPUT
20080125_1438< Hidden> and that reroute thing does not work properly with foreign addresses
20080125_1438< jengelh> so let me get this straight. Fake saddr, and packet is MARKed, is not routed correctly?
20080125_1438< Hidden> yes
20080125_1439< jengelh> can't believe it :P
20080125_1439< Hidden> exactly
20080125_1439< Hidden> but it's netfilter mangle which causes the problem
20080125_1440< Hidden> when it detects that the packet has changed and tries to re-route it
20080125_1440< jengelh> according to http://www.imagestream.com/~josh/PacketFlow-new.png , the route happens after mangle
20080125_1440< Hidden> exactly
20080125_1440< Hidden> that's why a -j MARK on mangle/OUTPUT breaks tproxy
20080125_1440< jengelh> so the routing code does not know that the mark was changed
20080125_1440< jengelh> hence can't do anything wrong
20080125_1441< jengelh> unless there is another hidden routing circle
20080125_1441< Hidden> forget what I said about the mark value not being considered by the routing code
20080125_1441< Hidden> that's not true
20080125_1442< Hidden> the problem is that ip_route_me_harder() does some checks
20080125_1442< Hidden> and those don't work for non-local source addresses
20080125_1442< jengelh> obviously :P
20080125_1442< Hidden> sorry, have to go now, I'll be back in 10 minutes
20080125_1442< jengelh> me2


--- Day changed Thu Jan 31 2008
20080131_1507< pa> hi
20080131_1508< pa> how can i mark incoming packets related to a connections for which outgoing packets are being marked?
20080131_1513-!- _ruben [n=ruben@84.244.141.35] has quit [Read error: 113 (No route to host)]
20080131_1518-!- achindra [n=achindra@59.95.9.132] has joined #netfilter
20080131_1519-!- achindra [n=achindra@59.95.9.132] has quit [Remote closed the connection]
20080131_1528-!- _ruben [n=ruben@84.244.141.35] has joined #netfilter
20080131_1534-!- acidfu [n=acidfu@59.94.224.20] has quit [Remote closed the connection]
20080131_1652-!- acidfu [n=acidfu@59.94.224.19] has joined #netfilter
20080131_1733-!- cosorio [n=cosorio@64.76.133.162] has joined #netfilter
20080131_1738-!- cosorio [n=cosorio@64.76.133.162] has quit ["Leaving"]
20080131_1739-!- acidfu [n=acidfu@59.94.224.19] has quit [Read error: 110 (Connection timed out)]
20080131_1816< pa> i found a patch to allow -m owner also on INPUT chain, but it seems for 2.6.11 and from 2.6.20+ it does not work any longer
20080131_1816< pa> any info?
20080131_1816< pa> is this chan totally dead?
20080131_1820-!- acidfu [n=acidfu@59.94.224.20] has joined #netfilter
20080131_1822-!- acidfu_ [n=acidfu@59.94.254.182] has joined #netfilter
20080131_1825< acidfu_> jengelh, so the default mark for a connection is "0" ?
20080131_1845-!- acidfu [n=acidfu@59.94.224.20] has quit [Connection timed out]
20080131_1904< jengelh> acidfu_: that seems to be the case yes. nfmark, ctmark and secmark are 0 by default
20080131_1904< jengelh> acidfu_: you can also explicitly set a 0 value if you desire
20080131_1905< jengelh> pa: alling owner on INPUT requires tproxy which .... all in all is not the in the kernel - yet
20080131_1905< jengelh> Boinc: whatever you like to call it
20080131_1905< jengelh> Boinc: just a filename
20080131_1920-!- [a]ton is now known as aton`
20080131_1932-!- Morphous [n=jan@dslb-088-076-146-103.pools.arcor-ip.net] has joined #netfilter
20080131_1932< pa> tproxy?
20080131_1932< pa> ok thanks
20080131_1948< pa> jengelh, i meant this module: http://svn.netfilter.org/cgi-bin/viewcvs.cgi/branches/patch-o-matic-ng/linux-2.6.11/owner-socketlookup/
20080131_1948< pa> i am looking for tproxy, but i dont understand much
20080131_1948-!- Morphous_ [n=jan@dslb-088-076-180-091.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
20080131_1956< pa> jengelh, eventually, couldnt i mark a connection whose packets i match in OUTPUT with -m owner so that in input i can have the connection marked?
20080131_2033-!- cohan [n=cohan@pdpc/supporter/active/cohan] has quit [Remote closed the connection]
20080131_2039-!- cohan [n=cohan@pdpc/supporter/active/cohan] has joined #netfilter
20080131_2210< pa> but if i mark an outgoing connection with connmark, how can i do to get incoming packets from that connection marked as wqell?
20080131_2210< pa> anyways that damn patch would be just great, if only it worked on 2.6.23
20080131_2211< Gandalf_> mangle prerouting -j CONNMARK --restore-mark or something like that
20080201_0105-!- aton` is now known as [a]ton
20080201_0127< pa> obviously i cant mark udp cause they are connectionless right?


--- Day changed Wed Apr 02 2008
20080402_1203< Hidden> gug
20080402_1207< _ruben> gug
20080402_1211< jengelh> blubb
20080402_1211< jengelh> don't you just idle!
20080402_1212< Hidden> glugg
20080402_1213< jengelh> just what are you doing, coding-wise?
20080402_1219< Hidden> well, not much these days
20080402_1220< Hidden> I'm trying to get the tproxy tree back into shape
20080402_1220< Hidden> now we have a public git repo to make things simpler
20080402_1220< Hidden> git://people.netfilter.org/hidden/tproxy.git

- also available as: https://people.netfilter.org/hidden/tproxy/

20080402_1220< jengelh> how different is it from panther's?
20080402_1223< Hidden> he's supposed to be publishing patches incremental to mine
20080402_1223< Hidden> and I merge them back into this tree
20080402_1223< Hidden> but as far as I know at the moment mine is more up-to-date
20080402_1223< Hidden> (in sync with yesterday's net-2.6.26)
20080402_1224< Hidden> but we still have missing bits
20080402_1224< Hidden> your xt_socket integration work is missing completely
20080402_1224< Hidden> ICMP is not working properly
20080402_1224< Hidden> and we have some more work to do to support bridging
20080402_1233< jengelh> wiring up some xt modules here
20080402_1249< xkr47> gug
20080402_1249< jengelh> xkr is on  heh
20080402_1249< xkr47> ?-)
20080402_1250< jengelh> something I wanted, but forget
20080402_1250< xkr47> you want me ?-D
20080402_1251< jengelh> got some netfilter stuff?
20080402_1251< xkr47> nothing new, sorry
20080402_1251< jengelh> trying to remember what it was that i wanted
20080402_1251< xkr47> I just have this simple flow picture
20080402_1252< xkr47> and some page listing updates in ipt -> xt structs
20080402_1252< xkr47>  (during 2.6 series)
20080402_1252< jengelh> ah I guess that was it
20080402_1252< jengelh> a recent patch to 2.6.24 just obsoleted 50% of all flow pics :p
20080402_1253< xkr47> stable series ?
20080402_1253< jengelh> hm?
20080402_1254< xkr47> so what is the patch about ?
20080402_1254-!- acidfoo [n=acidfu@59.94.236.177] has quit [Read error: 111 (Connection refused)]
20080402_1254< jengelh> see 2bf540b73ed5b304e84bb4d4c390d49d1cfa0ef8
20080402_1254< aspect> what's the patch? Does it make my problem easier to address? (that's multiple clients with the same IP)
20080402_1255< jengelh> aspect: what problem is there?
20080402_1255< jengelh> problems? what? 8-D
20080402_1255< aspect> jengelh: you're the one that pointed me to RAWNAT for it :-)
20080402_1256< jengelh> no, 2bf54 is about hook ordering in conjunction with bridge device output. hardly something related to rawnat.
20080402_1256< aspect> righto. I'll wait till I've got a keyboard to install this server with and see if I can get it going with some magics or taking up the RAWNAT patch :)
20080402_1257< xkr47> jengelh, a quick look makes me think my picture is so simple that it isn't affected :)
20080402_1257< jengelh> xkr47: correct.
20080402_1258< jengelh> xkr47: fwiw, http://jengelh.hopto.org/images/nf-packet-flow.png contains everything besides xgress

- nowadays here: https://en.wikipedia.org/wiki/File%3aNetfilter-packet-flow.svg

20080402_1258< jengelh> incl. encap/decapsulation
20080402_1301< xkr47> it's a good picture
20080402_1302-!- kugitsou [n=kugitsou@21.84-49-192.nextgentel.com] has quit []
20080402_1302< xkr47> but the link layer vs network layer is a bit unclear to me
20080402_1303< jengelh> that's who calls the boxes
20080402_1303< xkr47> okay.. so for example mangle forward gets called by both net & link layer after the routing decision
20080402_1303< xkr47> or does the routing decision affect which path is taken ?
20080402_1304< jengelh> it does
20080402_1304< jengelh> should change it
20080402_1304< xkr47> sorry, which one did you answer yes to ? :)
20080402_1304< xkr47> my fault, I asked it as one question :)
20080402_1306< jengelh> pic updated. -EAGAIN.
20080402_1307< xkr47> I guess there's the same kind of decision making before mangle postrouting
20080402_1307< jengelh> not that I know of.
20080402_1308< xkr47> hmm
20080402_1308< jengelh> I have not checked, honestly ... :)
20080402_1308< cirrus> jengelh: what is the "reroute check" after mangle/OUTPUT?
20080402_1309< jengelh> when routing parameters were changed.
20080402_1309< cirrus> so I can change the previous routing decision there?
20080402_1309< jengelh> in reality, you can only change the fwmark
20080402_1310< jengelh> yes, you can cause the routing to select a different route if you change the packet mark or the TOS field
20080402_1310< cirrus> so the kernel will re-evaluate the ip rules if the fwmark has been modified in OUTPUT?
20080402_1310< jengelh> no, it recalculates the route.
20080402_1310< cirrus> hmmm that means the route is calculated twice for each packet
20080402_1310< jengelh> only if you changed a parameter.
20080402_1311< cirrus> ah. thanks for clarification (and the nice graph), interesting feature which I wasn't aware of.
20080402_1311< jengelh> well, it sucks.
20080402_1311< jengelh> the reroute check would have made much more sense after nat.
20080402_1312< jengelh> if you DNAT in output, things wreak havoc if the interface would be changing as a result of the DNAT.
20080402_1312< cirrus> here we have 3 internet lines, and it's been difficult to write the rules so we can decide in PREROUTING..
20080402_1312< jengelh> and you can't change the destination address in mangle because that confuses conntrack
20080402_1312< jengelh> i have not yet had a scenario where it is difficult
20080402_1313< jengelh> in the worst case it's just a bunch of duplicated rules
20080402_1313< cirrus> `iptables-save |wc -l` = 1125 ...
20080402_1315< jengelh> then you did something wrong :D
20080402_1315< cirrus> no, I'm using ferm and it's way too easy to generate many many many rules ;)
20080402_1316< cirrus> most of this is filters for customer IP addresses for stuff like nagios, that could be optimized with ipset


--- Day changed Tue May 13 2008
20080513_2151-!- edde [n=x@c83-254-129-146.bredband.comhem.se] has joined #netfilter
20080513_2159< edde> hi, is it possible to set mark from an app through a sockopt or something?
20080513_2159< edde> I'd like to match on any packet originating from a specific socket
20080513_2208< jengelh> Yes.
20080513_2208< jengelh> actually, you set a mark on the socket (the fd), so that generated packets inherit a default mark (you can still change it through iptables)
20080513_2211< jengelh> setsockopt(fd, SOL_SOCKET, SO_MARK, 1337); where 1337 is the mark value
20080513_2212< jengelh> edde: 
20080513_2213< edde> thnx
20080513_2213< jengelh> needs CAP_NET_ADMIN privileges of course
20080513_2213< edde> thats fine for now :)
20080513_2213< edde> thats exactly what I need
20080513_2214< edde> Whats the deal with the owner module and the cmd-owner btw? it's obsolete?
20080513_2214< jengelh> matching pid/sid/command is a costly operation (especially the more processes you have)
20080513_2215< jengelh> other than that it is being said to be ugly, not SMP safe, blah, etc.
20080513_2215< jengelh> and also, multiple commands can have the socket open
20080513_2215< jengelh> then again, each process can modify its own command as seen by the kernel or ps
20080513_2216< edde> yes thats right, but it is very useful sometimes
20080513_2216< jengelh> well there's a better (but non-existent) solution
20080513_2216< jengelh> also, xt_owner should really be named xt_socket instead


--- Day changed Wed Jun 11 2008
20080611_2006< xkr47> the good thing I can always use my aged pom-ng I have a copy of
20080611_2006< xkr47> and port the modules I need
20080611_2006< jengelh> the good thing is it won't work with 1.4.1
20080611_2006< xkr47> only thing I lost with 2.6.18 was the owner match
20080611_2006< Romster> lol...
20080611_2006< jengelh> owner is in 2.6. something
20080611_2006< xkr47> 2.6.12 or .13
20080611_2006< jengelh> no
20080611_2006< xkr47> jengelh, you redid iptables totally ? :P
20080611_2007< jengelh> xkr47: you should look at it
20080611_2007< xkr47> well maybe .14, but no later
20080611_2007< jengelh> xt_owner has never been removed
20080611_2007< xkr47> after that they stripped down owner
20080611_2007< Romster> i've poked around seems neater
20080611_2007< xkr47> down to unusefulnes for me
20080611_2007< jengelh> stripped yes, for valid reasons.
20080611_2007< xkr47> kaber considered it "unfixable" and removed the functionality
20080611_2007< xkr47> although I think there has been some rumours about it coming back, dunno
20080611_2007< jengelh> iirc woodhause considered it unfixable
20080611_2008< xkr47> ok
20080611_2008< jengelh> the only rumour there was is that xt_socket would supercede xt_owner
20080611_2008< jengelh> supersede.
20080611_2008< jengelh> (i.e. rename)
20080611_2008< Romster> take it's place.
20080611_2008-!- hard__ware [n=HardwarE@unaffiliated/firebot] has quit [Read error: 110 (Connection timed out)]
20080611_2008< jengelh> owner was a misnomer
20080611_2009< xkr47> will there be a possibility to match users and/or process names of incoming packets ?
20080611_2009< xkr47> (users/uids)
20080611_2009< jengelh> what if multiple processed have a socket open?
20080611_2009< jengelh> think dup() and fork()
20080611_2009< Romster> wasn't there a process match module..
20080611_2010< xkr47> in that case, the user defines wanteed behaviour
20080611_2010< Romster> ouch that could get nasty.
20080611_2010< xkr47> "one match is enough" or "all must match"
20080611_2010< xkr47> or similar options, as necessary
20080611_2010< jengelh> yeah but C.Lameter was not happy with the locking
20080611_2011< jengelh> or someone
20080611_2011< xkr47> yeah I figured, since the issue you presented isn't really a blocker logically
20080611_2011< jengelh> 34b4a4a624bafe089107966a6c56d2a1aca026d4

- https://github.com/torvalds/linux/commit/34b4a4a624bafe089107966a6c56d2a1aca026d4

20080611_2011< jengelh> C.Hellwig.
20080611_2012< jengelh> but then again I would not care because the locking would only affect users of xt_owner
20080611_2012< xkr47> the hash leads me to think it was either disabled or implemented in this commit; which is it ?
20080611_2012< Romster> match what program name and mark the dscp pool 2 to later hit the gateway pc to be classified i had something like that in mind, it would nearly remove the need for l7-filter.
20080611_2012< jengelh> disabled
20080611_2013< xkr47> would it unleash a sea of deadlocks to implement it or just be damned hard or imply lots of new locking in code otherwise not needing it or... ?
20080611_2013< jengelh> none of that
20080611_2013< jengelh> it would just lock the whole kernel for a period that core developers are not willing to accept
20080611_2014< xkr47> is this why it was disabled in 2.6.1[234] or why it will not be implemented in 2.6.2x or ..?
20080611_2014< xkr47> i.e. will it come back through some other mechanism ? apparmor could be one way perhaps, I think it has gotten some network functionality in 2.6.2x..
20080611_2015< jengelh> Yes, I thought of LSMs.
20080611_2015< jengelh> That would at least make it possible to make it available in the output path.
20080611_2015< Romster> how hard would it be to do pgrep foo get the id and use that to mark packets?
20080611_2016< jengelh> -m string --string "foo" -j MARK
20080611_2016< Romster> program id=mark no.
20080611_2016< jengelh> program id?
20080611_2016< Romster> err process id..
20080611_2016< xkr47> well input path also, since the process & socket would already have been resolved.. but that would also cut down the options like DROP etc
20080611_2016< jengelh> there is also a solution for the input path but noone merged it yet...
20080611_2016< Romster> string is just a label..
20080611_2016< jengelh> for input hm
20080611_2017< jengelh> up to the socket level, but not the proc level
20080611_2017< xkr47> aha
20080611_2017< xkr47> ok, well if you stumble upon it sometimes, I'm interested
20080611_2017< xkr47> but you don't need go find it now at least for my part
20080611_2017< xkr47> thanks for the info
20080611_2018< jengelh> but what would you need it for
20080611_2018< xkr47> I used to use it for limiting which processes could access the internet
20080611_2018< jengelh> -A OUTPUT -m owner --process "evil" -j DROP
20080611_2018< xkr47> (and vice versa)
20080611_2018< jengelh> might be ok
20080611_2018< jengelh> but for INPUT...
20080611_2019< xkr47> it was problematic, sure, since a lot of context is missing in iptables..
20080611_2019< xkr47> which is kindof what socket resolving code is working around..
20080611_2019< xkr47> (on input)
20080611_2020< xkr47> btw, does linux allow data to be included in the SYN packet?
20080611_2020< jengelh> you can always try, but the linux api does not
20080611_2020< xkr47> yeah I know
20080611_2021< Romster> maybe if you made a raw socket.. *shrugs*
20080611_2021< xkr47> I was just wondering if that would be a loophole if only output blocking was used.. in which case some data would already have been passed
20080611_2021< jengelh> only when constructing the packet yourself you get to have the luxury. And that's limited to PF_RAW programs and kernelspace.
20080611_2021< Romster> then again the kernel could null all that out.
20080611_2021< jengelh> there are no holes.
20080611_2022< xkr47> Romster, right, one could mangle the incoming tcp packet as if it didn't contain any data
20080611_2022< Romster> you thinking of a syn payload packet.
20080611_2022< xkr47> then the returning syn-ack would only ack the SYN and the remote end would resend the data
20080611_2023< Romster> yeah
20080611_2023< xkr47> of course this would need some checksum etc recalculating, but hey that's what mangle is all about!! ;)
20080611_2023< Romster> hehe
20080611_2023< Romster> one day i might try my hand at making some modules.
20080611_2023< Romster> if i see a real need.
20080611_2024< Romster> but right now i got enough todo.
20080611_2024< xkr47> I have some custom modules, "tcpack" for example for matching tcp packets with no payload
20080611_2024< xkr47> I use it in my qos to put "acks" in a different class
20080611_2024< Romster> hmm interesting.
20080611_2025< xkr47> I almost got it merged, but people wanted it to be more generic and I couldn't get myself motivated enough :P
20080611_2025< xkr47> so it never got to pom-ng
20080611_2025< Romster> ah well.
20080611_2025< xkr47> I still use it tho :
20080611_2025< xkr47> :)
20080611_2025< jengelh> xkr47: that's pointless
20080611_2026< jengelh> -p tcp --tcp-flags ACK ACK -m length --layer5 --length 0
20080611_2026< xkr47> that didn't exist two years ago!
20080611_2026< Romster> hehe
20080611_2026< xkr47> so don't come shoving no pointless in my face!
20080611_2026< xkr47> that surely must have evolved from my initial idea
20080611_2026< jengelh> actually no.
20080611_2026< xkr47> so you should be thanking me instead ;)
20080611_2027< jengelh> it came from http://jengelh.medozas.de/documents/Chaostables.pdf where 0-sized packets indicate a grab
20080611_2027< xkr47> hehe
20080611_2027-!- danieldg [n=me@about/networking/240.0.0.0/danieldg] has quit [Remote closed the connection]
20080611_2027< xkr47> anyway, that's what kaber wanted me to implement and I didn't..
20080611_2027-!- danieldg [n=me@about/networking/240.0.0.0/danieldg] has joined #netfilter
20080611_2028< xkr47> (sorry for getting carried away, but your "pointless" suggestion was just totally wrong)
20080611_2028< Romster> touchie <<
20080611_2030< xkr47> I would agree that in the presence of this enhanced length filter it would be pointless for _others_ to use my less generic one
20080611_2031-!- debacle [n=debacle@host219-254-dynamic.181-80-r.retail.telecomitalia.it] has quit [Read error: 110 (Connection timed out)]
20080611_2034< Romster> i wouldn't say it's pointless xkr47 learned from it.
20080611_2034< Romster> and omg... Fujitsu Announces 5 TB Hard Disk Drives
20080611_2038-!- netsrot [n=netsrot@213507835-KEMAB-BREDBAND-NET.host.songnetworks.se] has quit ["leaving"]
20080611_2040< xkr47> yeah and it works for me..
20080611_2102< Romster> it would be saying something is pointless when back there there was no other implementation although i would say it's pointless to make one now when there is a solution already.
20080611_2102< Romster> hmm i'm getting something to eat.


--- Day changed Thu Jul 24 2008
20080724_1840< al_> is there a way to match a process id?
20080724_1840< al_> i can see there's something in the owner module, but it's flagged "revision 0" and broken
20080724_1848< xkr47> if you use 2.6.12, then yes, if 2.6.14-2.6.2x then no, if 2.6.2y then maybe
20080724_1853< Hidden> oh, and what's x an y?
20080724_1854< xkr47> no idea
20080724_1900< al_> actually the code i'm referring to is netfilter trunk
20080724_1900< jengelh> there is no trunk
20080724_1901< jengelh> we ain't using svn
20080724_1901< al_> gdmmit, that's what google spitted out :)
20080724_1901< jengelh> what is broken?
20080724_1902< al_> oh, git, shiny :)
20080724_1903< al_> broken? nothing. i'm just looking for a replacement of --pid-owner functionality, as i'm being told: iptables v1.4.1.1: Unknown arg `--pid-owner'
20080724_1903< al_> with the owner module that is
20080724_1903< jengelh> removed.
20080724_1904< al_> yep, i noticed
20080724_1904< al_> i was wondering if there's a replacement
20080724_1904< jengelh> no
20080724_1905< jengelh> it was fundamentally broken
20080724_1905< Regit> al_: nufw ;)
20080724_1907< al_> Regit: sounds interesting
20080724_1907< al_> but also expensive
20080724_1907< al_> resource-wise


--- Day changed Tue Nov 18 2008
20081118_1505-!- derRichard [n=derRicha@ununbium.nod.at] has joined #netfilter
20081118_1517< derRichard> is it possible to find out the process id from a packet which was queued in nf_queue?
20081118_1517< derRichard> the process id which has generated the packet...
20081118_1518< Regit> derRichard: What are you trying to achieve ?
20081118_1519< derRichard> just for fun. i want to queue all outgoing packets (e.g iptables -A OUTPUT -j NFQUEUE ..) and find out which programm has them sent
20081118_1519< derRichard> something like a personal firewall. i want do know which programms are calling home :)
20081118_1520< derRichard> (i'm aware of that personal firewall are crap)
20081118_1520< Regit> derRichard: ok, you can't :D
20081118_1521< j_engelh> you need one of the LSM solutions to figure that one out
20081118_1521< Regit> ysorry
20081118_1522< derRichard> j_engelh: hmm, good idea
20081118_1526< derRichard> has it a particular reason why it is impossible to get the pid?
20081118_1527< j_engelh> derRichard: because it is ugly
20081118_1527< derRichard> ugly to implement in netfilter?
20081118_1527< j_engelh> and your result may be no PID at all, or more than one.
20081118_1528< j_engelh> at least, with the classic iptables approach
20081118_1528< derRichard> hm, no pid is clear. but how can a packet "have" more than one pids?
20081118_1529< j_engelh> because iptables used to check for which process had the socket
20081118_1529< j_engelh> which is inherently flawed too
20081118_1530< derRichard> ahhh *checked* :)
20081118_1531< derRichard> e.g. apache has a lot of processes which share the same socket?
20081118_1531< j_engelh> derRichard: dunno, but a simple fork() is enough to cause such behavior
20081118_1532< j_engelh> which is why LSMs are needed
20081118_1532< derRichard> ok, i'll have a look at lsm
20081118_1532< j_engelh> like tuxguardian or that other thing whose name I've forgot again
20081118_1533< derRichard> tuxguardian looks nice :)
20081118_1536-!- shoonya [n=unknown@122.166.8.199] has quit ["Leaving"]
20081118_1537< derRichard> wow! lsm is really cool.
20081118_1556< sam_synack> derRichard: I'm working on a such tool http://www.synack.fr/project/cn_net/cn_net.html
20081118_1709< derRichard> sam_synack: nice. i'll have a loot at it
20081118_1713< derRichard> sam_synack: do you already have a public git-repo? (i'm looking at your release plan ;))
20081118_1722< sam_synack> derRichard: I got one, but it's not yet public
20081118_1722< sam_synack> derRichard: I will make a release this week end
20081118_1722< sam_synack> derRichard: I know there is a lack of informations currently
20081118_1722< derRichard> ok :)
20081118_1723< j_engelh> sam_synack: is the CONFIG_CONNECTOR?
20081118_1732< sam_synack> j_engelh: sorry ?
20081118_1732< j_engelh> That "connector", is it the same as the in-kernel CONFIG_CONNECTOR code?
20081118_1733< sam_synack> no, CONFIG_CONNECTOR is the tool to send netlink messages between kernel and userspace
20081118_1733< sam_synack> s/tool/tool used/
20081118_1734< sam_synack> cn_net is using this tool to reports syscalls


--- Day changed Wed Jul 22 2009
20090722_0136-!- photon [n=photon@unaffiliated/photon] has joined #netfilter
20090722_0144< mharris> I've got an older system with iptables rulesets that take advantage of the "-m owner --cmd-owner <command>" match extension which works quite nicely, however newer versions of iptables do not appear to support that anymore citing incompatibilities with SMP systems.
20090722_0145< mharris> The machine I'm using it on right now is actually SMP and it works fine as far as I can tell, but I do want to upgrade that machine and am wondering if there is any alternative method to get a similar working feature?
20090722_0146< orb> matching by command name is stupid anyhow
20090722_0146< orb> programs can freely choose their name, thereby --cmd-owner providing no security
20090722_0146< mharris> I've found it useful in diagnosing
20090722_0146< mharris> I'm just using it with -j LOG for diagnostics
20090722_0147< orb> hm
20090722_0147< mharris> I agree with you however
20090722_0148< orb> The problem is that it requires the tasklist lock, and is your tasklist is large, you'll get a projected bad delay
20090722_0148< mharris> I could use netstat and other tools to get the same information I suppose
20090722_0148-!- Romster [n=romster@unaffiliated/romster] has joined #netfilter
20090722_0149< mharris> It would however be nice to be able to do something like "permit /usr/bin/foo ability to make outgoing TCP connections on port 80"
20090722_0149< mharris> I'll have to investigate how to fiddle with SElinux policy for that perhaps
20090722_0150< mharris> orb: good point
20090722_0151< orb> for filtering use http://www.synack.fr/project/snet/snet.html
20090722_0156< mharris> interesting, thanks


--- Log opened Wed Nov 25 07:38:37 2009
20091125_1446-!- DeadPanda [n=brett@150.204.48.81] has joined #netfilter
20091125_1452-!- j_engelh is now known as d_sun
20091125_1458< Snicksie> i, i got a question; i got a vpn-connection where i can only transfer some files with a server, but not use all the other things like browsing/chat/whatever. i know it's possible to play a bit with iptables to be able to use my normal connection to do everyting, except vpn, what should be forwarded to the pptp tunnel, so i can both use normal connection and pptptunnel instead of disconnecting my normal connection. How can I do this?
20091125_1501-!- Romster [n=romster@unaffiliated/romster] has quit ["reboot"]
20091125_1501-!- corretico [n=laguilar@201.201.46.106] has joined #Netfilter
20091125_1502< DeadPanda> Is there anything in the conntrack API to retrieve the process ID responsible for opening the socket?
20091125_1502< jordan`> hi, in case you don't have you can still borrow some code from netstat to do this (which i did a few years ago)
20091125_1504< DeadPanda> ah, thanks jordan, didn't think of that - just started on this today :(
20091125_1506-!- Romster [n=romster@unaffiliated/romster] has joined #netfilter
20091125_1524<@d_sun> DeadPanda: I am not sure that's even possible nor meaningful
20091125_1526< DeadPanda> d_sun, meaningful for what I'm trying to achieve, which is information flow tracking - need to tie network connections to processes/users
20091125_1528<@d_sun> Well consider what happens if two processes have an fd to the socket. Then you are screwed.
20091125_1529<@d_sun> That said, there are credentials attached to the socket who created it (not who is using it..)
20091125_1530< DeadPanda> d_sun, it's reasonable to track both - working with probability, not certainty
20091125_1530<@d_sun> I think I submitted a patch for that
20091125_1530< DeadPanda> d_sun, and taking a VMM approach, just using this to get some sample data to test the analysis process
20091125_1532<@d_sun> http://bugzilla.netfilter.org/show_bug.cgi?id=600
20091125_1532< e_> eh
20091125_1532< e_> selinux can do that
20091125_1532< e_> -> auditd
20091125_1533< DeadPanda> ah, perfect - thanks e_
20091125_1533<@d_sun> auditd also runs without selinux :)
20091125_1533-!- mode/#netfilter [-o d_sun] by ChanServ
20091125_1533< e_> and vice versa
20091125_1533< e_> nonetheless 
20091125_1533< e_> :)
20091125_1534< DeadPanda> hehe, that saves me a lot of work here, figured I'd have to implement it - cheers all
20091125_1534< d_sun> see the patch on bug 600
20091125_1549-!- SpeedyG [n=speedyg@unaffiliated/speedyg] has quit [Read error: 110 (Connection timed out)]
20091125_1553< sam_synack> DeadPanda: well, what ? tracking the creator is easy, and if you need to access all the fd users, it will be fine to add this feature to the kernel, if it's not already possible
20091125_1554-!- SpeedyG [n=speedyg@ip51cc64f6.adsl-surfen.hetnet.nl] has joined #netfilter
20091125_1555< d_sun> No, it's not fine to add this to the kernel (tracking each processes) - we used to do that with -m owner --pid-owner, which, you know, got removed
20091125_1555< d_sun> improvements welcome tho :p
20091125_1556< sam_synack> well, because you are thinking about filtering packet, which is not the good layer for this
20091125_1556< sam_synack> you are talking about process and fd
20091125_1558< sam_synack> i'm working on this using LSM modules
20091125_1558< sam_synack> http://www.synack.fr/project/cn_net/cn_net.html
20091125_1558< sam_synack> ans the newer approach : http://www.synack.fr/project/snet/snet.html
20091125_1559< sam_synack> s/ans/and/
20091125_1604< d_sun> done yet? :D
20091125_1606< sam_synack> it's working, yes
20091125_1607< sam_synack> I wish I add time to re-submit the new version to upstream
20091125_1609-!- FinboySlick [n=shark@207.134.8.4] has joined #netfilter
20091125_1614-!- DeadPanda [n=brett@150.204.48.81] has quit [Remote closed the connection]


--- Day changed Tue Dec 29 2009
20091229_1837-!- n_vas_n [n=n_vas_n@58samana90.codetel.net.do] has joined #netfilter
20091229_1837-!- Genohunter [n=Geno@wprt-4db6dc32.pool.mediaWays.net] has joined #netfilter
20091229_1838< n_vas_n> hi
20091229_1838< n_vas_n> can I have ownercmd works in 2.6 ?
20091229_1839-!- Stellvia_ [n=Stellvia@cB932BF51.dhcp.bluecom.no] has quit [Connection timed out]
20091229_1839-!- corretico__ [n=laguilar@201.201.46.106] has quit ["Leaving"]
20091229_1840-!- corretico [n=laguilar@201.201.46.106] has joined #Netfilter
20091229_1840< n_vas_n> actually I would like to know can it work at all
20091229_1840< n_vas_n> I need to filter some apps
20091229_1841< bc547> xNinja: youtube has lot and lots of ip's... why don't you want it passing your proxy?
20091229_1842< bc547> n_vas_n: I believe it was removed
20091229_1842< n_vas_n> yes? I know
20091229_1842< n_vas_n> ,
20091229_1842< n_vas_n> ,=?
20091229_1842< n_vas_n> i know that
20091229_1842< n_vas_n> but I need it
20091229_1843< n_vas_n> the question is - can do it or not?
20091229_1843< n_vas_n> because I do not see anything similar
20091229_1844< bc547> n_vas_n: probably it is removed for a good reason... so I think the answer to your question is 'not'
20091229_1845< n_vas_n> and what the reason was?
20091229_1846< bc547> n_vas_n: no idea
20091229_1846< n_vas_n> to not allow anyone to know what does go out of the "very secure" linux
20091229_1846-!- David^ [i=Cache-@87-194-150-34.bethere.co.uk] has quit [Client Quit]
20091229_1846< n_vas_n> this is only reason
20091229_1848< bc547> n_vas_n: why do think that is the only reason?
20091229_1849< n_vas_n> this "very secure" linux allow everything installed to send outside whatever it wants
20091229_1849< n_vas_n> and no one can even control it
20091229_1850< n_vas_n> very difficult to monitor
20091229_1850-!- corretico [n=laguilar@201.201.46.106] has quit [Read error: 104 (Connection reset by peer)]
20091229_1851< n_vas_n> even mac have app level firewall, in linux nothing, why?
20091229_1852-!- Genoo [n=Geno@wprt-4db6f914.pool.mediaWays.net] has quit [Read error: 113 (No route to host)]
20091229_1852< n_vas_n> mac has, sorry
20091229_1854< Romster> did you not look at man iptabes at the -m owner module?
20091229_1855< Romster> it's in iptables 1.4.6
20091229_1855< n_vas_n> yes
20091229_1856< n_vas_n> there is no --cmd-owner
20091229_1856< Romster> nope 
20091229_1857< n_vas_n> so
20091229_1857< n_vas_n> that is the point
20091229_1857< Romster> why do you need that and i can't even remember what it did
20091229_1857< n_vas_n> it filter application
20091229_1858< n_vas_n> you can control where certain app wants to go
20091229_1859< n_vas_n> and allow or not
20091229_1859< n_vas_n> was very good idea
20091229_1859< bc547> n_vas_n: have you looked at AppArmor ?
20091229_1900< n_vas_n> it cant filter IP traffic
20091229_1900< n_vas_n> it can allow or disallow
20091229_1900< n_vas_n> but not filter
20091229_1900< Romster> doesn't look like xtables-addons has anything of use in that regard either.
20091229_1901< Romster> i did remember a pid match
20091229_1901< bc547> n_vas_n: and systrace?
20091229_1901-!- corretico [n=laguilar@201.201.46.106] has joined #Netfilter
20091229_1901< n_vas_n> I can't allow for example to Opera connect ONLY to port 80
20091229_1902< n_vas_n> what is systrace and how it can filter IP traffic?
20091229_1902-!- Netsplit jordan.freenode.net <-> irc.freenode.net quits: spectra, Kjikaqawej
20091229_1903< bc547> n_vas_n: http://en.wikipedia.org/wiki/Systrace
20091229_1904< n_vas_n> An application is allowed to make only those system calls specified as permitted in the policy.
20091229_1905< n_vas_n> It is not what I want
20091229_1905< Romster> what happend to the pid match module :/
20091229_1905< n_vas_n> I want to control, where apps connected
20091229_1905< n_vas_n> where in internet
20091229_1905< n_vas_n> removed as well
20091229_1908-!- Netsplit jordan.freenode.net <-> irc.freenode.net quits: Amorphous
20091229_1908< Romster> the owner match had a --pid-owner option
20091229_1908-!- Netsplit over, joins: Amorphous
20091229_1908< Romster> iptables -A OUTPUT -m owner --pid-owner 78
20091229_1908< Romster> This match is used to match packets based on the Process ID (PID) that was responsible for them. This match is a bit harder to use, but one example would be only to allow PID 94 to send packets from the HTTP port (if the HTTP process is not threaded, of course). Alternatively we could write a small script that grabs the PID from a ps output for a specific daemon and then adds a rule for it. For an example, you could have a rule as shown in the 
20091229_1908< Romster> Pid-owner.txt example. 
20091229_1909< Romster> i'm sure that's what you were after n_vas_n ?
20091229_1909< n_vas_n> there is no  --pid-owner
20091229_1909< n_vas_n> NO
20091229_1909< n_vas_n> NO
20091229_1909< Romster> bah
20091229_1909< n_vas_n> removed
20091229_1909< Romster> forget it
20091229_1909< n_vas_n> that is why I'n asking
20091229_1909< Romster> write your own.
20091229_1910< n_vas_n> thanks
20091229_1910< Romster> seems no one else finds it useful.
20091229_1910< Romster> pgrep foo get pid match against that.
20091229_1910< n_vas_n> perfect "botnet" - no one can control nothing
20091229_1911< Romster> http://www.linuxfocus.org/English/February2005/article367.shtml that might still apply
20091229_1913< n_vas_n> yes but kernel is not support some useful features anymore
20091229_1914< n_vas_n> one can write anything - it is useless
20091229_1914< n_vas_n> it should be in kernel
20091229_1914-!- Stellvia [n=Stellvia@cB932BF51.dhcp.bluecom.no] has quit [Read error: 60 (Operation timed out)]
20091229_1915< n_vas_n> linux - future "linux-bot-net"
20091229_1915-!- spectra [i=spectra@debian/developer/spectra] has joined #netfilter
20091229_1915< n_vas_n> every thing is ready
20091229_1915-!- Bart[mdv] [n=bart@i.love.freenode.and.solarnet.ru] has quit [Read error: 60 (Operation timed out)]
20091229_1915< n_vas_n> i start to hate it
20091229_1916< n_vas_n> selinux - difficult
20091229_1916< n_vas_n> some distros even disable it
20091229_1918-!- Stellvia [n=Stellvia@cB932BF51.dhcp.bluecom.no] has joined #netfilter
20091229_1919-!- Bart[mdv] [n=bart@i.love.freenode.and.solarnet.ru] has joined #netfilter
20091229_1922-!- Netsplit jordan.freenode.net <-> irc.freenode.net quits: Stellvia
20091229_1924-!- Netsplit jordan.freenode.net <-> irc.freenode.net quits: Amorphous
20091229_1925-!- Netsplit over, joins: Amorphous
20091229_1925< Romster> simple remove any user accounts that abuse there rights.
20091229_1927< bc547> or force user webtraffic to pass a local webproxy 
20091229_1927-!- Stellvia [n=Stellvia@cB932BF51.dhcp.bluecom.no] has joined #Netfilter
20091229_1931< n_vas_n> web - traffic
20091229_1931< n_vas_n> if it is not web traffic
20091229_1931< n_vas_n> who knows what it will be
20091229_1931-!- Stellvia_ [n=Stellvia@cB932BF51.dhcp.bluecom.no] has joined #netfilter
20091229_1931< n_vas_n> how can I prevent port to be given to any apps?
20091229_1932< n_vas_n> what if I don't want to let to listen any ports
20091229_1934-!- githogori_ [n=githogor@adsl-66-123-22-146.dsl.snfc21.pacbell.net] has quit [Client Quit]
20091229_1934< bc547> n_vas_n: apparmor
20091229_1934< n_vas_n> it can allow or disallow
20091229_1934< bc547> n_vas_n: that will be the closest to what you want I guess
20091229_1935< n_vas_n> --cmd-owner
20091229_1935< n_vas_n> --cmd-owner -j mi_filter_dist
20091229_1935-!- Stellvia [n=Stellvia@cB932BF51.dhcp.bluecom.no] has quit [Connection timed out]
20091229_1936< bc547> n_vas_n: that is not available anymore... so that does not count at the moment
20091229_1937< n_vas_n> i just want you understand my needs, I want to control application traffic
20091229_1937< n_vas_n> that is all
20091229_1937< n_vas_n> I did it always on windows
20091229_1937< n_vas_n> it was very easy
20091229_1938< n_vas_n> and I was very sure that linux has even better - but not
20091229_1938< n_vas_n> linux - worse then windows
20091229_1938< bc547> n_vas_n: then use windows?
20091229_1939< n_vas_n> it is not a solution
20091229_1942-!- xuser [n=xuser@unaffiliated/xuser] has quit [Remote closed the connection]
20091229_1944-!- David^ [i=Cache-@87-194-150-34.bethere.co.uk] has joined #netfilter
20091229_1946< n_vas_n> windows in the past


Many more people come in, for years, asking for pid & cmd-owner matches, and get replies "it was removed years ago"...


--- Day changed Fri Sep 03 2010
20100903_1337< consolers> windows 7 firewall can match against exe names. netfilter doesnt even come close
20100903_1337< mtrg> the patch is likely to get into linux code officially too
20100903_1337< sn6> consolers: Because you are comparing the wrong things.
20100903_1338< mtrg> consolers: windows firewall didn't get the .exe name from the network packet
20100903_1338< consolers> no, it gives more flexibility, like when i want to block outgoing traffic
20100903_1338< sn6> for process matching, you have to use an LSM like snet, or tomoyo, or..
20100903_1338< consolers> even now my present problem is i cant put a --owner match on INPUT
20100903_1338< sn6> Hello McFly. Anybody home?
20100903_1339< sn6> By the time a packet reaches INPUT, we have not even passed the packet on to the TCP stack, so there is no knowledge of where it would end up at.
20100903_1340< consolers> well, or have some other mechanism --- i described my problem above
20100903_1341< mtrg> i guess netfilter is a network filter isn't it
20100903_1341< mtrg> is not userlandFilter kind of thing
20100903_1341< sn6> No, Netfilter is an API at best. Xtables is the packet filter.


--- Day changed Wed Nov 10 2010
... huge preceding discussion cut out...
20101110_0317< rsca> xelister: Well, if there's no owner info (left), it won't be accepted with your ruleset
20101110_0317< rsca> so yeah, use -m conntrack --ctstate ESTABLISHED for the time
20101110_0318< rsca> as TPR says, that you should use anyway and only filter NEW
20101110_0318< xelister> ok, so that is the work around. neat
20101110_0318< xelister> not always working matching by UID can possibly have some security implications if it would be a negative rule (to drop) well, and would hinder logging
20101110_0319< xelister> btw, rsca, as you probably noticed, dropping this unknown-UID packet does not seem to have any effect on firefox working, so it is not the imporatant data carrying packet it would seem
20101110_0321< rsca> as far as userspace is concerned, the connection is likely already terminated, but the tcp engine still has to finish off the closing handshake
20101110_0321< rsca> so it is, in a way, important
20101110_0325-!- sigius [~sigius@93-125-185-45.dsl.alice.nl] has joined #Netfilter
20101110_0325< xelister> so overall the practice is rather to only filter NEW packets,  and always allow ESTABLISHED?
20101110_0325< xelister> perhaps this is why this bug was unnoticed. Anyway not many admins take advantage of using uid match :/
20101110_0327< danieldg> usually you allow ESTABLISHED on the theory that the connection was already allowed once
20101110_0329< rsca> UID matching is unrealiable because the user may use several EUIDs (think ping - runs as root, thus socket belongs to root)
20101110_0329< rsca> second, the output path may not run in user context, so you can't just do current->uid
20101110_0329< xelister> yeah
20101110_0330< xelister> would be nice to in future fix that
20101110_0330< rsca> synack wrote an LSM (because that does run in user ctx
20101110_0330< xelister> and allow again pid and cmd matching
20101110_0330-!- scampbell [~scampbell@mail.scampbell.net] has quit [Quit: vanished]
20101110_0330< rsca> pid matching does not make sense to me, and cmd ... well you can forge cmds
20101110_0330< rsca> furthermore, traversing the task list is a costly operation
20101110_0330< rsca> which is why it was removed
20101110_0330< xelister> that was available afair around 2005 but later got droped due to some implementation problems
20101110_0331< xelister> without such maching
20101110_0331< xelister> how can linux do triviall thing that most windows firewalls can do since like year 2000
20101110_0331< xelister> allow given connections only for given program
20101110_0331< danieldg> selinux security label matching
20101110_0331< xelister> right, other then apparmor
20101110_0331< xelister> and selinux
20101110_0332< danieldg> because the windows way has 1000 holes in it
20101110_0332< xelister> and this is the reason for not protecting linux?!
20101110_0332< danieldg> if you want to do it, do it right
20101110_0332< danieldg> use selinux, or different uids
20101110_0333< xelister> this is what im doing
20101110_0333< xelister> but cant have 100 uids for user to run every app separatelly
20101110_0333< danieldg> that's what android does
20101110_0334< danieldg> if you don't like that model, use something like selinux with a label for each app
20101110_0334< danieldg> but that's a pain to set up too
20101110_0334< xelister> apparmor also seems interesting
20101110_0334< xelister> but probably grsecurity is better
20101110_0334< rsca> If you wanna know how much pain it is to even write a firewall, as the guy who did netfilter for win32
20101110_0334< rsca> ask.
20101110_0335< rsca> And you don't want to know what speed impact all those windows firewall products have
20101110_0335< danieldg> I haven't set up grsec, not sure how it enforces the confinement
20101110_0336< danieldg> basically, if you don't prevent apps from debugging or launching other apps, trying to firewall them off is just feel-good security
20101110_0336< mancha> there was a thing floating about called snet (heard about it from rsca i think)
20101110_0336< mancha> dunno where that is, it is certainly not mainlined
20101110_0337< rsca> but it had been posted for mainline already (which is more than most other projects :)
20101110_0337< danieldg> linux does have network namespaces as part of cgroups now, so that's another way
20101110_0338< mancha> secmark is probably a good approach to this. what lsm's mark these days aside from selinux?
20101110_0338< mancha> does tomoyo, smack?
20101110_0338< rsca> afaics yes
20101110_0340< mancha> will they ever be stackable again?!
20101110_0340< xelister> danieldg: grsec does strong MAC, and capabilities also adds more readonly/debugging/randomizations/kernel verification and sanitation etc
20101110_0340< xelister> grsecurity > tomoyo, apparmor
20101110_0341< mancha> i don't like to heavily patch my kernels though. you like grsec eh?
20101110_0341< danieldg> xelister: are they trying for mainline inclusion or not?
20101110_0341< xelister> danieldg: partially.  also <kees> of ubuntu security team asks for more such inclusions, see lkml
20101110_0342< mancha> they sucessfully got apparmor in (after novell didn't have such luck)
20101110_0343-!- tuxcrafter [~jelle@84-245-3-195.dsl.cambrium.nl] has quit [Read error: Operation timed out]
20101110_0343< rsca> mancha: won't be stackable
20101110_0343< mancha> afaik apparmor doesn't do secmarking (yet?)
20101110_0343< rsca> mancha: but splitting stuff up allows to plug in different architectures for different subsystems (snet, sfs, ...) - so far the theory
20101110_0344< rsca> "ubuntu" and "security" in one word. And then they spew out yama LSM. *headshake*
20101110_0344-!- tuxcrafter [~jelle@84-245-3-195.dsl.cambrium.nl] has joined #Netfilter
20101110_0344< cj> maxine: hello?
20101110_0345-!- maxine [~maxine@router0.colliertech.org] has joined #Netfilter
20101110_0345-!- maxine [~maxine@router0.colliertech.org] has quit [Changing host]
20101110_0345-!- maxine [~maxine@unaffiliated/cj/bot/maxine] has joined #Netfilter
20101110_0345< cj> maxine: hello?
20101110_0345< maxine> howdy cj
20101110_0349< mancha> rsca did you ever try out the snet patches?
20101110_0350< rsca> No
20101110_0350< mancha> iirc it's a netlink that sends stuff to userspace for managing?
20101110_0351< danieldg> netlink can be used for that, yes; and it's the preferred method
20101110_0351< danieldg> NFQUEUE target
20101110_0351-!- Amorphous [jan@unaffiliated/amorphous] has quit [Ping timeout: 265 seconds]
20101110_0352< mancha> right except contrary to using nfqueue say, snet uses lsm to hook into system calls bind() connect() ec
20101110_0352< mancha> *etc
20101110_0352< xelister> rsca: we can probably wireshark'ed the connection to see the packet
20101110_0353< xelister> unless you figured out what is the last non-uid packet?
20101110_0354< rsca> xelister: it's the ACK to a FIN
20101110_0402< mancha> so netfilter is late to the game?
20101110_0403< mancha> rsca didn't quite follow your comment on stacking, snet can currently co-exist with selinux or apparmor?
20101110_0404-!- Amorphous [jan@unaffiliated/amorphous] has joined #Netfilter
20101110_0404< xelister> why can't one security hook call another?
20101110_0404< xelister> would be cool to allow using  tomoyo and grsecurity and apparmor - if someone is really crazy/paranoid ;) (and not minding performance penalty)
20101110_0405< mancha> that isn't possible now, they can't be stacked.
20101110_0406< mancha> however i *think* rcsa as suggesting a related concept to stacking, that is specialization, this lsm module for this subsystem and this other one for that subsystem
20101110_0406< mancha> this would be good since some solutions can do {a,b,c} another {b,d} and another only {e}
20101110_0407< xelister> indeed
20101110_0408< xelister> I ment, would be cool to allow stacking (and also specialization)
20101110_0408< xelister> I wonder what forbids stacking
20101110_0408< xelister> i.e. what are the technical difficulties
20101110_0408< mancha> politics and some influential groups idea of what constitutes a sane and sound security infrastructure for the kernel
20101110_0409< xelister> damn politics
20101110_0415-!- pr3d4t0r [~cu4cu4@varenka.cime.net] has joined #Netfilter
20101110_0415< pr3d4t0r> Greetings.
20101110_0415< pr3d4t0r> Q. What's the maximum number of entries that you can add to the DROP or REJECT IP tables?  Thanks in advance.
20101110_0415< mancha> xelister tomoyo, iirc, has high granularity control for application usage of network capabilities
20101110_0415< pr3d4t0r> I'm running a script that's /banning IP addresses at a rate of ~30/minute; a few of my web servers were hit by a botnet based on specific content.
20101110_0415< rsca> mancha: no, there is no stacking. not now and not in the future
20101110_0415< rsca> xelister: because of semantics
20101110_0416< rsca> pr3d4t0r: until you run out of memory
20101110_0416< pr3d4t0r> rsca: OKi.
20101110_0416< pr3d4t0r> rsca: Thanks.
20101110_0417-!- skulls [debian-tor@gateway/tor-sasl/skulls] has quit [Remote host closed the connection]
20101110_0417< pr3d4t0r> rsca: Theoretically an iptables flush every few hours should be OKi - I have 4 GB/RAM per server, with about 2 GB free.  I expect the attack to subside in 24 - 36 hours.
20101110_0417< mancha> xelister it also has confinement capabilities that extend beyond path-based mcls though, it is a pretty solid ifrastructure. i am puzzled by its relative unpopularity
20101110_0418< mancha> except maybe for the rh/selinux force
20101110_0418-!- spoljo [~spoljo@li149-238.members.linode.com] has joined #Netfilter
20101110_0420< xelister> mancha: you mean grsec?
20101110_0421< xelister> I guess some DAMN FUCKING POLITICS again are responsible?
20101110_0421< mancha> danieldg, i am interested in the cgroups angle, do you have working knowledge of this?
20101110_0421< danieldg> no
20101110_0421< mancha> xelister, i am not sure about grsecurity at all. how hard they pushed for mainlining or if there are good reasons to bar entry
20101110_0423< xelister> well imho
20101110_0423< xelister> apparmor is shit compared to grsecurity
20101110_0423< xelister> and same for tomoyo
20101110_0423< xelister> let me just say, apparmor is blacklist-only approach......
20101110_0424< mancha> i don't think there is much love for pax's acl design
20101110_0424< mancha> what do you mean blacklist-only?
20101110_0424< mancha> when confined, the default in apparmor is "deny"
20101110_0424< xelister> but all process are by default not confined
20101110_0425< xelister> so ALL user-installed apps have NO PROTECTION WHAT SO EVER (afair) so this is crap
20101110_0425< mancha> and the tcp/ip stack is by default unrestricted too
20101110_0425< mancha> etc, i don't see this as a problem. you can easily in apparmor set a generic deny profile.
20101110_0426< mancha> much like you can in selinux, set a default restricted confinement and then allocate permissions
20101110_0426< xelister> is this now possible in apparmor?  ok then, much better in fact
20101110_0427< xelister> stil lgrsec have like +30 more options and protections
20101110_0427< xelister> and the MAC/RBAC is also more advanced
20101110_0427 * xelister bases on infor from around 2009/2010
20101110_0428< mancha> i think the kernel folks like mac a lot more than rbac which is probably why grsec is not in
20101110_0428< mancha> grsec is still a less-to-more approach right?
20101110_0429< mancha> it would be good to ask some users of hardened gentoo (i think that uses grsec) what they think
20101110_0431-!- sigius [~sigius@93-125-185-45.dsl.alice.nl] has quit [Ping timeout: 250 seconds]
20101110_0431< mancha> sorry for going so off-topic netfilter folks got carried away by my interest  :)
20101110_0433< pr3d4t0r> Have a nice evening, Everyone.