bsdpot / pot

pot: another container framework for FreeBSD, based on jails, ZFS and pf
BSD 3-Clause "New" or "Revised" License
343 stars 31 forks source link

Add support for the IPFW and/or IPF firewalls OR make pot firewall-agnostic #56

Open debdrup opened 5 years ago

debdrup commented 5 years ago

The one thing missing from pot, I think, is making pot either capable of using either or both IPFW and IPF, since both have people who actively use and maintain them.

Another option which is arguably better but may involve more work (and changing ABI/KBI and would thus probably involve a major version bump?) would be to adopt a principle similar to that of blacklistd. It uses a firewall-agnostic API where the sysadmin supplies the commands necessary for certain functions, and then that command is simply executed. This would have the added benefit that if, say, npf (NetBSD Packet Filter by rmind@netbsd) was ever ported to FreeBSD, or another 4th firewall was added, it would be trivial to add support for these.

pizzamig commented 5 years ago

Thanks for show interest on this. However what you ask, It's not easy. the first thing I'd like to work is to rework the pf support using anchor. I can rework this part of the code to be "firewall independent". In this way, it should be easier to add support to other firewalls.

debdrup commented 5 years ago

Ah, I see - well, it doesn't have to be right now, and it's better to get it done properly when you're going to be doing it - so as long as it gets done, it doesn't have to be soon. I think it would also give pot an advantage over many of the other similar tools, so there's something to consider. :)

Crest commented 5 years ago

IPFW tables could really simplify things because they're key-value maps instead of just sets and the mapped value(s) can be used as part of the argument to ipfw actions e.g. forward to this address and port. I' m willing to look into this. I suspect that everything pot needs can be expressed in IPFW with a short fixed set of rules.

Crest commented 4 years ago

I look into what firewall features pot uses so far and found this:

Since pot already makes use of FreeBSD specific features here is how I would like to improve this:

This could at the very least extend the existing hooks for:

Additional hooks could be added to handle network interfaces (physical interface for alias and inherit, bridge+epair for vnet):

Pot should include at least one default implementation for each type of hook to work out of the box and serve as example.

@pizzamig : How do you think about this design proposal?

Crest commented 4 years ago

An other question is how these hooks should be stored. Right now pot export doesn't preserve the hooks on the exported jail. This is a problem because for some setups these hooks are required e.g. to add jails to PF tables.

pizzamig commented 4 years ago

first the easy question: hooks are copied in the conf folder of the pot. To make them part of an exported jail, you have to take the snapshot AFTER the set-hook. pot export generates the image from the last available snapshot, not the current status.

Design proposal: honestly it seems very complicated to me and it needs a major rework.

My original idea about firewall was this: define a set of functions to use the firewall, kind of an API. Then, provide an implementation for pf and another one for ipfw and let the user choose.

In general, I stand to support only 1 hook, it's a good way to extend pot and try new features, that at the end should be integrated in the framework.

Support multiple hooks needs a lot of work and time, that unfortunately I don't have right now...

grembo commented 4 years ago

first the easy question: hooks are copied in the conf folder of the pot. To make them part of an exported jail, you have to take the snapshot AFTER the set-hook. pot export generates the image from the last available snapshot, not the current status.

Design proposal: honestly it seems very complicated to me and it needs a major rework.

My original idea about firewall was this: define a set of functions to use the firewall, kind of an API. Then, provide an implementation for pf and another one for ipfw and let the user choose.

In general, I stand to support only 1 hook, it's a good way to extend pot and try new features, that at the end should be integrated in the framework.

Support multiple hooks needs a lot of work and time, that unfortunately I don't have right now...

@pizzamig @Crest I feel like this is the kind of improvement that should come as a pull request from someone who is using pot in production and requiring that feature.

Crest commented 4 years ago

I asked because I have a use-case that isn't covered by the existing features e.g. UDP based services and automatic IPv6 aliases. Scripting around those limitations with the existing hooks and ansible is possible, but time consuming and fragile.

Crest commented 4 years ago

I just revisited the design and there is no reason to embed support for multiple hooks on a single jail/interface into pot. Should the user want this a hook can be used to loop over the other hooks with whatever merge and shortcut behaviour fits his usecase.