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,
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
>>
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 comple
* 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 bypa
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
* 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
> > 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, bec
* 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]
* 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
* 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
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..
> > 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 generat
> 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
> ta
> 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 ide
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 furthe
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 t
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
#include
+#include
+
void filt_sordetach(struct knote *kn);
intfilt_soread(
> 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
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 s
e-
> From: Giancarlo Razzolini <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> 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
Giancarlo Razzolini <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> 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 PROTEC
ini <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
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:
> * Giancarl
his ssh -w 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
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
* 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
scott escreveu:
> openBSD(4.2) and 4.3-beta
>
> /etc/pf.conf fragment
> # ---v---
> pass in log quick on em0 inet proto tcp \
> from ! to (em0:0) port 22 \
> tag SSHVPN flags S/SA keep state \
> (max-src-conn-rate 3/120, overload flush global) \
> label R1
> #
> pass out log quick on em1 tagge
* 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
openBSD(4.2) and 4.3-beta
/etc/pf.conf fragment
# ---v---
pass in log quick on em0 inet proto tcp \
from ! to (em0:0) port 22 \
tag SSHVPN flags S/SA keep state \
(max-src-conn-rate 3/120, overload flush global) \
label R1
#
pass out log quick on em1 tagged SSHVPN keep state \
label R2
#
blo
28 matches
Mail list logo
