hmm so by the way.. it was a mistake form my side, the pf.conf takes
the @ if the rule is:
block out on fxp1 tagged @foo
instead of:
block out on fxp1 tagged @foo
I allready implement it and test it would work, the question for me
is, if the uid would be necessary and the namespace is enough,
* Can Erkin Acar [EMAIL PROTECTED] [2008-03-06 22:43]:
Hey
so now I changed the tagging from tcp_output to ip_output.
I also put an pf_tag_unref to so_free and sosetopt (in case that there
is allready a tag set).
I couldn't see a reason for a pf_tag_unref in the so_accept because
the
* Konrad [EMAIL PROTECTED] [2008-03-06 21:13]:
so now I changed the tagging from tcp_output to ip_output.
yes, that is much better I think.
I also put an pf_tag_unref to so_free and sosetopt (in case that there
is allready a tag set).
great!
I couldn't see a reason for a pf_tag_unref in
* Henning Brauer [EMAIL PROTECTED] [2008-03-07 13:45]:
* Konrad [EMAIL PROTECTED] [2008-03-06 21:13]:
so now I changed the tagging from tcp_output to ip_output.
yes, that is much better I think.
oh, what about ip6_output? :)
--
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web
I couldn't see a reason for a pf_tag_unref in the so_accept because
the socket could be reused.
don't we need an additional ref (aka tagname2tag or the like), not unref,
since the socket gets cloned?
if you want a diffrent tag on the resulting socket, then we have a
problem, because if
* Konrad [EMAIL PROTECTED] [2008-03-07 15:01]:
I couldn't see a reason for a pf_tag_unref in the so_accept because
the socket could be reused.
don't we need an additional ref (aka tagname2tag or the like), not unref,
since the socket gets cloned?
if you want a diffrent tag on
On Fri, 7 Mar 2008, Konrad wrote:
Nice, you probably want to keep the application/kernel tag name spaces
distinct though. Otherwise it would be easy for any local user/program
to mess with pf.conf generated tags and bypass filtering etc. It could
be as easy as adding a prefix (APP_ ?) to all
* Dave Anderson [EMAIL PROTECTED] [2008-03-07 17:34]:
On Fri, 7 Mar 2008, Konrad wrote:
Nice, you probably want to keep the application/kernel tag name spaces
distinct though. Otherwise it would be easy for any local user/program
to mess with pf.conf generated tags and bypass filtering
So now I added the ip6_output and I think i got a solution for the
accept, but I'm not 100% sure if that is enough. I tested it and it
looked fine. I couldn't test the ip6_output, because i don't have the
enviroment for it till now :) I'll hope to do this tommorw.
The '@'-thing is something
On Fri, 7 Mar 2008, Henning Brauer wrote:
* Dave Anderson [EMAIL PROTECTED] [2008-03-07 17:34]:
On Fri, 7 Mar 2008, Konrad wrote:
Nice, you probably want to keep the application/kernel tag name spaces
distinct though. Otherwise it would be easy for any local user/program
to mess with
So sorry its not a propper diff anymore but this is what i've done:
--- sys.bak/kern/uipc_socket.c Wed Mar 5 21:11:31 2008
+++ sys/kern/uipc_socket.c Thu Mar 6 06:50:29 2008
@@ -48,6 +48,8 @@
#include sys/resourcevar.h
#include sys/pool.h
+#include net/pfvar.h
+
void
replying in public, since there are at least two people hacking on that
* Konrad [EMAIL PROTECTED] [2008-03-06 10:26]:
So sorry its not a propper diff anymore but this is what i've done:
unfortunatly this is not enough. it messes the refcounting.
the tagname2tag routing keeps a refcount for the
Hey
so now I changed the tagging from tcp_output to ip_output.
I also put an pf_tag_unref to so_free and sosetopt (in case that there
is allready a tag set).
I couldn't see a reason for a pf_tag_unref in the so_accept because
the socket could be reused.
Thanks to Henning for the ideas!
Any
Hey
so now I changed the tagging from tcp_output to ip_output.
I also put an pf_tag_unref to so_free and sosetopt (in case that there
is allready a tag set).
I couldn't see a reason for a pf_tag_unref in the so_accept because
the socket could be reused.
Thanks to Henning for the ideas!
Nice, you probably want to keep the application/kernel tag name spaces
distinct though. Otherwise it would be easy for any local user/program
to mess with pf.conf generated tags and bypass filtering etc. It could
be as easy as adding a prefix (APP_ ?) to all application generated
tags.
Nice, you probably want to keep the application/kernel tag name spaces
distinct though. Otherwise it would be easy for any local user/program
to mess with pf.conf generated tags and bypass filtering etc. It could
be as easy as adding a prefix (APP_ ?) to all application generated
On 2008-03-06, Can Erkin Acar [EMAIL PROTECTED] wrote:
I am not sure how you could to change the 'kernel' tag names and
become transparent/compatible at the same time.
It wouldn't work anyway, then the app could set it's tag to
KERNEL_whatever and the conflict would still exist..
Hi everybody,
I like henning's idea to use something like a setsockopt(2) option to
assign a pf tag to a running session. I was thinking about this
before to use it with some weird magic in relayd... but this is way
off at the moment.
I liked the idea, too. So here is what I've done so
Hi everybody,
I like henning's idea to use something like a setsockopt(2) option to
assign a pf tag to a running session. I was thinking about this
before to use it with some weird magic in relayd... but this is way
off at the moment.
I liked the idea, too. So here is what I've
Subject: Re: pf tag goes missing post sshd tcp decapsulization
Date: Mon, 03 Mar 2008 13:02:02 -0300
Mailer: Thunderbird 1.5.0.14pre (X11/20071023)
Delivered-To: [EMAIL PROTECTED]
Henning Brauer escreveu:
* Giancarlo Razzolini [EMAIL PROTECTED] [2008-03-03 14:35]:
Tags are only visible while
openBSD(4.2) and 4.3-beta
/etc/pf.conf fragment
# ---v---
pass in log quick on em0 inet proto tcp \
from !ssh_pests to (em0:0) port 22 \
tag SSHVPN flags S/SA keep state \
(max-src-conn-rate 3/120, overload ssh_pests flush global) \
label R1
#
pass out log quick on em1 tagged SSHVPN keep
* scott [EMAIL PROTECTED] [2008-03-03 10:10]:
Something about the sshd's tcp decapsulization or pf's relationship with
it is loosing the tag SSHVPN.
yes, since that happens in userland, tags are lost.
nothing you can do about it... it would be nice if userland apps could
mark a socket such
scott escreveu:
openBSD(4.2) and 4.3-beta
/etc/pf.conf fragment
# ---v---
pass in log quick on em0 inet proto tcp \
from !ssh_pests to (em0:0) port 22 \
tag SSHVPN flags S/SA keep state \
(max-src-conn-rate 3/120, overload ssh_pests flush global) \
label R1
#
pass out log quick on
* Giancarlo Razzolini [EMAIL PROTECTED] [2008-03-03 14:35]:
Tags are only visible while in the kernel. Once you send them to a
application, unless it has the ability to set a tag, the tag will be
lost. The ftp-proxy(8) AFAICR, since 4.1 has the ability to set a tag on
the packet. It would be
Henning Brauer escreveu:
* Giancarlo Razzolini [EMAIL PROTECTED] [2008-03-03 14:35]:
Tags are only visible while in the kernel. Once you send them to a
application, unless it has the ability to set a tag, the tag will be
lost. The ftp-proxy(8) AFAICR, since 4.1 has the ability to set a tag on
option is sooo very cool!!! It just needs a little more
something from the supporting cast of daemons.
Thx.
-Original Message-
From: Giancarlo Razzolini [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: misc@openbsd.org
Subject: Re: pf tag goes missing post sshd tcp decapsulization
Date
]
To: misc@openbsd.org
Subject: Re: pf tag goes missing post sshd tcp decapsulization
Date: Mon, 03 Mar 2008 13:02:02 -0300
Mailer: Thunderbird 1.5.0.14pre (X11/20071023)
Delivered-To: [EMAIL PROTECTED]
Henning Brauer escreveu:
* Giancarlo Razzolini [EMAIL PROTECTED] [2008-03-03 14:35]:
Tags are only
?
No, this is something that can be done. But instead i would recommend
some kind of captive portal (wicap) or authpf to the wifi sessions.
Thx.
-Original Message-
From: Giancarlo Razzolini [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: misc@openbsd.org
Subject: Re: pf tag goes missing post sshd tcp
28 matches
Mail list logo
