[patch] RFC: matching interface groups

[patch] RFC: matching interface groups

[Balazs Scheidler]

Hi,

I would like to easily match a set of dynamically created interfaces
from my packet filter rules. The attached patch forms the basis of my
implementation and I would like to know whether something like this is
mergeable to mainline.

The use-case is as follows:

* I have two different subsystems creating interfaces dynamically (for
example pptpd and serial pppd lines, each creating dynamic pppX
interfaces),
* I would like to assign a different set of iptables rules for these
clients,
* I would like to react to a new interface being added to a specific set
in a userspace application,

The reasons I see this needs new kernel functionality:

* iptables supports wildcard interface matching (for example "iptables
-i ppp+"), but as the names of the interfaces used by PPTPD and PPPD
cannot be distinguished this way, this is not enough,
* Reloading the iptables ruleset everytime a new interface comes up is
not really feasible, as it abrupts packet processing, and validating the
ruleset in the kernel can take significant amount of time,
* the kernel change is very simple, adapting userspace to this change is
also very simple, and in userspace various software packages can easily
interoperate with each-other once this is merged.

The implementation:

Each interface can belong to a single "group" at a time, an interface
comes up without being a member in any of the groups.

Userspace can assign interfaces to groups after being created, this
would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.

In spirit "interface group" is somewhat similar to the "routing
protocol" field for routing entries, which contains information on which
routing daemon was responsible for adding the given route entry.

Things to be done if you like this approach:

* interface group match in iptables,
* support for naming interface groups in userspace, a'la routing
protocols,
* emitting a netlink notification when the group of an interface
changes,
* possibly converting the "ip link" command to use NETLINK messages,
instead of using ioctl()

What do you think?

kernel patch:
-------------

* add a numeric ID to each interface in the system, denoting its
"interface group",


index df0cdd4..19a103a 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -736,6 +736,8 @@ enum
 #define IFLA_WEIGHT IFLA_WEIGHT
        IFLA_OPERSTATE,
        IFLA_LINKMODE,
+#define IFLA_IFGROUP IFLA_IFGROUP
+       IFLA_IFGROUP,
        __IFLA_MAX
 };

diff --git a/include/linux/sockios.h b/include/linux/sockios.h
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 3fcfa9c..26849af 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -279,6 +279,11 @@ static int rtnetlink_fill_ifinfo(struct
                u32 iflink = dev->iflink;
                RTA_PUT(skb, IFLA_LINK, sizeof(iflink), &iflink);
        }
+
+       if (dev->ifgroup) {
+               u32 ifgroup = dev->ifgroup;
+               RTA_PUT(skb, IFLA_IFGROUP, sizeof(ifgroup), &ifgroup);
+       }

        if (dev->qdisc_sleeping)
                RTA_PUT(skb, IFLA_QDISC,
@@ -459,6 +464,12 @@ static int do_setlink(struct sk_buff *sk
                dev->link_mode = *((u8 *) RTA_DATA(ida[IFLA_LINKMODE - 1]));
                write_unlock_bh(&dev_base_lock);
        }
+
+       if (ida[IFLA_IFGROUP - 1]) {
+               if (ida[IFLA_IFGROUP - 1]->rta_len != RTA_LENGTH(sizeof(u32)))
+                       goto out;
+               dev->ifgroup = *((u32 *) RTA_DATA(ida[IFLA_IFGROUP - 1]));
+       }

        if (ifm->ifi_index >= 0 && ida[IFLA_IFNAME - 1]) {
                char ifname[IFNAMSIZ];


ip route patch:
---------------

* added a "group" option to ip link set to make it possible to set this
id, and a way to print this option


diff --git a/ip/iplink.c b/ip/iplink.c
index ffc9f06..e694475 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -26,6 +26,7 @@
 #include <string.h>
 #include <sys/ioctl.h>
 #include <linux/sockios.h>
+#include <linux/rtnetlink.h>

 #include "rt_names.h"
 #include "utils.h"
@@ -44,6 +45,7 @@ void iplink_usage(void)
        fprintf(stderr, "                            promisc { on | off } |\n");
        fprintf(stderr, "                            trailers { on | off } |\n");
        fprintf(stderr, "                            txqueuelen PACKETS |\n");
+       fprintf(stderr, "                            group GROUP |\n");
        fprintf(stderr, "                            name NEWNAME |\n");
        fprintf(stderr, "                            address LLADDR | broadcast LLADDR |\n");
        fprintf(stderr, "                            mtu MTU }\n");
@@ -174,6 +176,28 @@ static int set_mtu(const char *dev, int
        return 0;
 }

+static int set_group(const char *dev, int ifgroup)
+{
+       struct {
+               struct nlmsghdr         n;
+               struct ifinfomsg        ifi;
+               char                    buf[256];
+       } req;
+
+       memset(&req, 0, sizeof(req));
+       req.n.nlmsg_len = NLMSG_LENGTH(sizeof(req.ifi));
+       req.n.nlmsg_flags = NLM_F_REQUEST;
+       req.n.nlmsg_type = RTM_SETLINK;
+
+       req.ifi.ifi_index = -1;
+
+       addattr_l(&req.n, sizeof(req), IFLA_IFNAME, dev, strlen(dev)+1);
+       addattr_l(&req.n, sizeof(req), IFLA_IFGROUP, &ifgroup, sizeof(ifgroup));
+       if (rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL) < 0)
+               return -1;
+       return 0;
+}
+
 static int get_address(const char *dev, int *htype)
 {
        struct ifreq ifr;
@@ -257,6 +281,7 @@ static int do_set(int argc, char **argv)
        __u32 mask = 0;
        __u32 flags = 0;
        int qlen = -1;
+       int group = 0;
        int mtu = -1;
        char *newaddr = NULL;
        char *newbrd = NULL;
@@ -289,6 +314,12 @@ static int do_set(int argc, char **argv)
                                duparg("txqueuelen", *argv);
                        if (get_integer(&qlen,  *argv, 0))
                                invarg("Invalid \"txqueuelen\" value\n", *argv);
+               } else if (matches(*argv, "group") == 0) {
+                       NEXT_ARG();
+                       if (group != 0)
+                               duparg("group", *argv);
+                       if (get_integer(&group, *argv, 0) || group == 0)
+                               invarg("Invalid \"group\" value\n", *argv);
                } else if (strcmp(*argv, "mtu") == 0) {
                        NEXT_ARG();
                        if (mtu != -1)
@@ -406,6 +437,10 @@ static int do_set(int argc, char **argv)
                                return -1;
                }
        }
+       if (group) {
+               if (set_group(dev, group) < 0)
+                       return -1;
+       }
        if (mask)
                return do_chflags(dev, flags, mask);
        return 0;


-- 
Bazsi

Re: [patch] RFC: matching interface groups

[Stephen Hemminger]

On Tue, 01 Aug 2006 19:10:09 +0200
Balazs Scheidler <bazsi@balabit.hu> wrote:

> Hi,
> 
> I would like to easily match a set of dynamically created interfaces
> from my packet filter rules. The attached patch forms the basis of my
> implementation and I would like to know whether something like this is
> mergeable to mainline.
> 
> The use-case is as follows:
> 
> * I have two different subsystems creating interfaces dynamically (for
> example pptpd and serial pppd lines, each creating dynamic pppX
> interfaces),
> * I would like to assign a different set of iptables rules for these
> clients,
> * I would like to react to a new interface being added to a specific set
> in a userspace application,
> 
> The reasons I see this needs new kernel functionality:
> 
> * iptables supports wildcard interface matching (for example "iptables
> -i ppp+"), but as the names of the interfaces used by PPTPD and PPPD
> cannot be distinguished this way, this is not enough,
> * Reloading the iptables ruleset everytime a new interface comes up is
> not really feasible, as it abrupts packet processing, and validating the
> ruleset in the kernel can take significant amount of time,
> * the kernel change is very simple, adapting userspace to this change is
> also very simple, and in userspace various software packages can easily
> interoperate with each-other once this is merged.
> 
> The implementation:
> 
> Each interface can belong to a single "group" at a time, an interface
> comes up without being a member in any of the groups.
> 
> Userspace can assign interfaces to groups after being created, this
> would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.
> 
> In spirit "interface group" is somewhat similar to the "routing
> protocol" field for routing entries, which contains information on which
> routing daemon was responsible for adding the given route entry.
> 
> Things to be done if you like this approach:
> 
> * interface group match in iptables,
> * support for naming interface groups in userspace, a'la routing
> protocols,
> * emitting a netlink notification when the group of an interface
> changes,
> * possibly converting the "ip link" command to use NETLINK messages,
> instead of using ioctl()
> 
> What do you think?

I like the concept, but it probably needs more review.

There is a bigger issue, which is how should the network device namespace
exist? There are virtualization efforts, that want to virtualize it,
and network device names have always lived in a parallel universe.
I don't expect your patch to solve this...

Re: [patch] RFC: matching interface groups

[Phil Oester]

On Tue, Aug 01, 2006 at 07:10:09PM +0200, Balazs Scheidler wrote:
> Each interface can belong to a single "group" at a time, an interface
> comes up without being a member in any of the groups.
> 
> Userspace can assign interfaces to groups after being created, this
> would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.

Since in this scenario userspace is able to determine ppp vs pptp, 
could you not also do something like have an inbound_ppp and inbound_pptp
chain, then jump to the appropriate chain depending on type?  If you
need per-interface rules, then create an inbound_pppX chain, populate
it with rules, then jump to that chain if -i pppX.  In ip-down, just
delete the chain as well as the jump.

Phil

Re: [patch] RFC: matching interface groups

[Sven Schuster]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]


Hi Phil,

On Tue, Aug 01, 2006 at 11:46:55AM -0700, Phil Oester told us:
> Since in this scenario userspace is able to determine ppp vs pptp, 
> could you not also do something like have an inbound_ppp and inbound_pptp
> chain, then jump to the appropriate chain depending on type?  If you
> need per-interface rules, then create an inbound_pppX chain, populate
> it with rules, then jump to that chain if -i pppX.  In ip-down, just
> delete the chain as well as the jump.

if I understood Balazs correctly, one of the things he wanted to
avoid is addition/deletion of iptables rules on every pppX interface
up/down as this would require the complete chain (say, INPUT or
OUTPUT) to be "downloaded" to userspace, modified and then again
"uploaded" to the kernel. At least until iptables redesign to
allow replacement/insertion/deletion of single rules is completed
which if started at all will take quite some more time :-)


Sven

> Phil
> 

-- 
Linux zion.homelinux.com 2.6.17-rc5-mm1_35 #35 Tue May 30 14:11:06 CEST 2006 i686 athlon i386 GNU/Linux
 21:13:05 up 19:46,  2 users,  load average: 0.22, 0.28, 0.27

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] RFC: matching interface groups

[Balazs Scheidler]

On Tue, 2006-08-01 at 21:18 +0200, Sven Schuster wrote:
> Hi Phil,
> 
> On Tue, Aug 01, 2006 at 11:46:55AM -0700, Phil Oester told us:
> > Since in this scenario userspace is able to determine ppp vs pptp, 
> > could you not also do something like have an inbound_ppp and inbound_pptp
> > chain, then jump to the appropriate chain depending on type?  If you
> > need per-interface rules, then create an inbound_pppX chain, populate
> > it with rules, then jump to that chain if -i pppX.  In ip-down, just
> > delete the chain as well as the jump.
> 
> if I understood Balazs correctly, one of the things he wanted to
> avoid is addition/deletion of iptables rules on every pppX interface
> up/down 

Exactly.

> as this would require the complete chain (say, INPUT or
> OUTPUT) to be "downloaded" to userspace, modified and then again
> "uploaded" to the kernel. At least until iptables redesign to
> allow replacement/insertion/deletion of single rules is completed
> which if started at all will take quite some more time :-)

Iptables operates on a per-table basis, so it is not only the INPUT or
OUTPUT chain that needs to be down and uploaded, but the whole filter
table.

And in addition, in my humble opinion the iptables ruleset should be up
to the user to maintain, once some kind of automatism starts to
add/remove rules on the fly, it becomes more difficult to do other
changes to add independent rules to the table. For example the user
needs to save the current ruleset using iptables-save, then modify the
resulting file, and then load it again. If the ruleset is generated as
it happens with a lot of tools, this might not be so easy.

-- 
Bazsi

Re: [patch] RFC: matching interface groups

[Balazs Scheidler]

On Tue, 2006-08-01 at 11:29 -0700, Stephen Hemminger wrote:
> On Tue, 01 Aug 2006 19:10:09 +0200
> Balazs Scheidler <bazsi@balabit.hu> wrote:
> 
> > Hi,
> > 
> > I would like to easily match a set of dynamically created interfaces
> > from my packet filter rules. The attached patch forms the basis of my
> > implementation and I would like to know whether something like this is
> > mergeable to mainline.
> > 
> > The use-case is as follows:
> > 
> > * I have two different subsystems creating interfaces dynamically (for
> > example pptpd and serial pppd lines, each creating dynamic pppX
> > interfaces),
> > * I would like to assign a different set of iptables rules for these
> > clients,
> > * I would like to react to a new interface being added to a specific set
> > in a userspace application,
> > 
> > The reasons I see this needs new kernel functionality:
> > 
> > * iptables supports wildcard interface matching (for example "iptables
> > -i ppp+"), but as the names of the interfaces used by PPTPD and PPPD
> > cannot be distinguished this way, this is not enough,
> > * Reloading the iptables ruleset everytime a new interface comes up is
> > not really feasible, as it abrupts packet processing, and validating the
> > ruleset in the kernel can take significant amount of time,
> > * the kernel change is very simple, adapting userspace to this change is
> > also very simple, and in userspace various software packages can easily
> > interoperate with each-other once this is merged.
> > 
> > The implementation:
> > 
> > Each interface can belong to a single "group" at a time, an interface
> > comes up without being a member in any of the groups.
> > 
> > Userspace can assign interfaces to groups after being created, this
> > would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.
> > 
> > In spirit "interface group" is somewhat similar to the "routing
> > protocol" field for routing entries, which contains information on which
> > routing daemon was responsible for adding the given route entry.
> > 
> > [snip]

> I like the concept, but it probably needs more review.
> 
> There is a bigger issue, which is how should the network device namespace
> exist? There are virtualization efforts, that want to virtualize it,
> and network device names have always lived in a parallel universe.
> I don't expect your patch to solve this...

I have read the OLS paper on virtualization, it states that the current
state of affairs is that struct net_device will be assigned to one
specific namespace. As my change changes struct net_device itself, I
expect to work without problems when virtualization comes, the interface
group can be interpreted on a per-namespace basis.

There probably will be several iptables rulesets when the time comes,
one for each namespace, but again, struct net_device will be assigned to
a namespace, and the proper iptables tables will be iterated based on
the net_device assignment.

Am I missing something?

-- 
Bazsi

Re: [patch] RFC: matching interface groups

[Amin Azez]

* Balazs Scheidler wrote, On 02/08/06 08:04:
> On Tue, 2006-08-01 at 21:18 +0200, Sven Schuster wrote:
>> as this would require the complete chain (say, INPUT or
>> OUTPUT) to be "downloaded" to userspace, modified and then again
>> "uploaded" to the kernel. At least until iptables redesign to
>> allow replacement/insertion/deletion of single rules is completed
>> which if started at all will take quite some more time :-)
> 
> Iptables operates on a per-table basis, so it is not only the INPUT or
> OUTPUT chain that needs to be down and uploaded, but the whole filter
> table.
> 
> And in addition, in my humble opinion the iptables ruleset should be up
> to the user to maintain, once some kind of automatism starts to
> add/remove rules on the fly, it becomes more difficult to do other
> changes to add independent rules to the table. For example the user
> needs to save the current ruleset using iptables-save, then modify the
> resulting file, and then load it again. If the ruleset is generated as
> it happens with a lot of tools, this might not be so easy.
> 

Even without this scenario it is not easily safe; if two interfaces
chanegd at the same time, two copies of iptables would be downloaded to
user space, both modified differently and the last one to be uploaded
would win, the other one loosing its changes.

This has bitten me and is one of my reasons for liking ipt_condition

Sam

[patch] RFC: matching interface groups

[Stephen J. Bevan]

Balazs Scheidler writes:
 > I would like to easily match a set of dynamically created interfaces
 > from my packet filter rules. The attached patch forms the basis of my
 > implementation and I would like to know whether something like this is
 > mergeable to mainline.
[snip]
 > The implementation:
 > 
 > Each interface can belong to a single "group" at a time, an interface
 > comes up without being a member in any of the groups.

You can get a similar effect by (ab)using the iflink field i.e. set
the iflink to the parent interface and modify
ip_tables.c:ip_packet_match to check the ifindex (or iflink if
defined) for a match.  An advantage of this is that it doesn't require
adding any new fields and the only kernel change is to
ip_tables.c:ip_packet_match (and its caller).  That said, an explicit
group (or zone as various firewall vendors call it) is cleaner.

Re: [patch] RFC: matching interface groups

[Gerd v. Egidy]

Hi,

> > > Since in this scenario userspace is able to determine ppp vs pptp,
> > > could you not also do something like have an inbound_ppp and
> > > inbound_pptp chain, then jump to the appropriate chain depending on
> > > type?  If you need per-interface rules, then create an inbound_pppX
> > > chain, populate it with rules, then jump to that chain if -i pppX.  In
> > > ip-down, just delete the chain as well as the jump.
> >
> > if I understood Balazs correctly, one of the things he wanted to
> > avoid is addition/deletion of iptables rules on every pppX interface
> > up/down
>
> Exactly.

We faced a similar problem: we wanted to not only differentiate between ppp 
and pptp interfaces but even between different providers connected via ppp 
and pptp.

We ended up predefining all possible providers in the rules and differentiate 
between them using the ipt_condition module. This module is not very 
well-loved in the netfilter community but there are usecases like this where 
it comes in handy.

Maybe this is a solution for you too.

> > as this would require the complete chain (say, INPUT or
> > OUTPUT) to be "downloaded" to userspace, modified and then again
> > "uploaded" to the kernel. At least until iptables redesign to
> > allow replacement/insertion/deletion of single rules is completed
> > which if started at all will take quite some more time :-)
>
> Iptables operates on a per-table basis, so it is not only the INPUT or
> OUTPUT chain that needs to be down and uploaded, but the whole filter
> table.

The problem with the current solution is not only speed and maintainability 
but also locking: if two device up/down events happen at the same time in 
this scenario, the tabels will become wrong until you develop some kind of 
userspace locking.

Kind regards,

Gerd

Re: [patch] RFC: matching interface groups

[Balazs Scheidler]

On Wed, 2006-08-02 at 21:08 -0700, Stephen J. Bevan wrote:
> Balazs Scheidler writes:
>  > I would like to easily match a set of dynamically created interfaces
>  > from my packet filter rules. The attached patch forms the basis of my
>  > implementation and I would like to know whether something like this is
>  > mergeable to mainline.
> [snip]
>  > The implementation:
>  > 
>  > Each interface can belong to a single "group" at a time, an interface
>  > comes up without being a member in any of the groups.
> 
> You can get a similar effect by (ab)using the iflink field i.e. set
> the iflink to the parent interface and modify
> ip_tables.c:ip_packet_match to check the ifindex (or iflink if
> defined) for a match.  An advantage of this is that it doesn't require
> adding any new fields and the only kernel change is to
> ip_tables.c:ip_packet_match (and its caller).  That said, an explicit
> group (or zone as various firewall vendors call it) is cleaner.

I could hack a solution together, but I'd prefer to do this cleanly,
preferably as a patch in mainline. I would like to incorporate this
functionality in our product.

-- 
Bazsi

Re: [patch] RFC: matching interface groups

[Patrick McHardy]

Balazs Scheidler wrote:
> The use-case is as follows:
> 
> * I have two different subsystems creating interfaces dynamically (for
> example pptpd and serial pppd lines, each creating dynamic pppX
> interfaces),
> * I would like to assign a different set of iptables rules for these
> clients,
> * I would like to react to a new interface being added to a specific set
> in a userspace application,
> 
> The reasons I see this needs new kernel functionality:
> 
> * iptables supports wildcard interface matching (for example "iptables
> -i ppp+"), but as the names of the interfaces used by PPTPD and PPPD
> cannot be distinguished this way, this is not enough,
> * Reloading the iptables ruleset everytime a new interface comes up is
> not really feasible, as it abrupts packet processing, and validating the
> ruleset in the kernel can take significant amount of time,
> * the kernel change is very simple, adapting userspace to this change is
> also very simple, and in userspace various software packages can easily
> interoperate with each-other once this is merged.
> 
> The implementation:
> 
> Each interface can belong to a single "group" at a time, an interface
> comes up without being a member in any of the groups.
> 
> Userspace can assign interfaces to groups after being created, this
> would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.
> 
> In spirit "interface group" is somewhat similar to the "routing
> protocol" field for routing entries, which contains information on which
> routing daemon was responsible for adding the given route entry.
> 
> Things to be done if you like this approach:
> 
> * interface group match in iptables,
> * support for naming interface groups in userspace, a'la routing
> protocols,
> * emitting a netlink notification when the group of an interface
> changes,
> * possibly converting the "ip link" command to use NETLINK messages,
> instead of using ioctl()
> 
> What do you think?


I like it .. kind of like routing realms. For your specific case there
is a possible solution already supported by the kernel, you can
pre-allocate ppp devices using PPPIOCNEWUNIT, rename them and later
attach to individual units in the ppp daemon using PPPIOCATTACH
(I have a patch for this somewhere if you're interested). But that
only works for PPP devices and the group idea looks more flexible.

Re: [patch] RFC: matching interface groups

[Balazs Scheidler]

On Fri, 2006-08-04 at 12:06 +0200, Patrick McHardy wrote:
> Balazs Scheidler wrote:
> > The use-case is as follows:
> > 
> > * I have two different subsystems creating interfaces dynamically (for
> > example pptpd and serial pppd lines, each creating dynamic pppX
> > interfaces),
> > * I would like to assign a different set of iptables rules for these
> > clients,
> > * I would like to react to a new interface being added to a specific set
> > in a userspace application,
> > 
> > The reasons I see this needs new kernel functionality:
> > 
> > * iptables supports wildcard interface matching (for example "iptables
> > -i ppp+"), but as the names of the interfaces used by PPTPD and PPPD
> > cannot be distinguished this way, this is not enough,
> > * Reloading the iptables ruleset everytime a new interface comes up is
> > not really feasible, as it abrupts packet processing, and validating the
> > ruleset in the kernel can take significant amount of time,
> > * the kernel change is very simple, adapting userspace to this change is
> > also very simple, and in userspace various software packages can easily
> > interoperate with each-other once this is merged.
> > 
> > The implementation:
> > 
> > Each interface can belong to a single "group" at a time, an interface
> > comes up without being a member in any of the groups.
> > 
> > Userspace can assign interfaces to groups after being created, this
> > would typically be performed in /etc/ppp/ip-up.d (and similar) scripts.
> > 
> > In spirit "interface group" is somewhat similar to the "routing
> > protocol" field for routing entries, which contains information on which
> > routing daemon was responsible for adding the given route entry.
> > 
> > Things to be done if you like this approach:
> > 
> > * interface group match in iptables,
> > * support for naming interface groups in userspace, a'la routing
> > protocols,
> > * emitting a netlink notification when the group of an interface
> > changes,
> > * possibly converting the "ip link" command to use NETLINK messages,
> > instead of using ioctl()
> > 
> > What do you think?
> 
> 
> I like it .. kind of like routing realms. For your specific case there
> is a possible solution already supported by the kernel, you can
> pre-allocate ppp devices using PPPIOCNEWUNIT, rename them and later
> attach to individual units in the ppp daemon using PPPIOCATTACH
> (I have a patch for this somewhere if you're interested). But that
> only works for PPP devices and the group idea looks more flexible.

Thanks for liking it :) I'm going to implement a complete patch with
iptables match and support for naming interface groups like routing
realms and post it when I'm ready.

I'd go for the more general solution as I have other interfaces not just
ppp, it was just a trivial example.

-- 
Bazsi