search

random-archer / mkinitcpio-systemd-tool

Provisioning tool for systemd in initramfs (systemd-tool)
https://www.archlinux.org/packages/community/any/mkinitcpio-systemd-tool/
Other
113 stars 27 forks source link

firewall inside initramfs #53

Closed vaminakov closed 4 years ago

vaminakov commented 4 years ago

I think it will be usefull to add nftables support to initrd-network.service Just add binary (if it's not already in) and /etc/nftables.conf to initrd. It can add full firewall functional to initrd - like knock, filter rules, etc. Any ideas what need to do that?

Andrei-Pozolotin commented 4 years ago

@vvl-rulez Vladislav: thank you for the suggestion

Any ideas what need to do that?

  1. there are 3 levels of "what can be done": a) easy-way: add *.conf and *.service and pray that it works b) better-way: add unit tests for path/link/text content of linux-initramfs.img c) the-right-way: add unit tests for features against live qemu instance of initrd machine

  2. here is a skeleton of "the-right-way" for "what needs to be done":

  3. please do as much as you can / want, I can finish the rest

vaminakov commented 4 years ago

@Andrei-Pozolotin 

2. here is a skeleton of "the-right-way" for "what needs to be done":

Today/tomorrow I'll test this and make changes in need. Thank you for work.

1. please do as much as you can / want, I can finish the rest

Sure. If all will work, I'll add to default package's config simple knock imlementation.

vaminakov commented 4 years ago

I've checked the code. I think that this realization is unresonable. And too hard to debug that :) Dropbear and tinyssh is not hard dependences of package, just optional. Maybe do nftables like that? Just add (in case of it installed) binaries, config to initramfs and that's all? (config file in /etc/mkinitcpio-systemd-tool/config/initrd-nftables.conf is good choise)

dvzrv commented 4 years ago

May I add, that similar to how with systemd-networkd we encourage having a different setup for initrd, this might also be the case for nftables. It is very unlikely to have the same setup in initrd and therefore the rootfs nftables.conf should not be used for that IMHO.

vaminakov commented 4 years ago

May I add, that similar to how with systemd-networkd we encourage having a different setup for initrd, this might also be the case for nftables. It is very unlikely to have the same setup in initrd and therefore the rootfs nftables.conf should not be used for that IMHO.

Sure - Andrey already did that. Config of initram's nft is /etc/mkinitcpio-systemd-tool/config/initrd-nftables.conf

Andrei-Pozolotin commented 4 years ago

I think that this realization is unresonable ...

sorry man, I do not quite understand what you mean by that comment block can you please use here both your native Russian and a google translate of that to English

vaminakov commented 4 years ago

sorry man, I do not quite understand what you mean by that comment block can you please use here both your native Russian and a google translate of that to English

Я имел ввиду, что реализация слишком сложная и нецелесообразная. Проще и выгоднее (наверное) использовать тот же метод, что и для tinyssh/dropbear. Т.е. не скачивание и установка в песочнице с питоном, а просто добавить nftables в optdepends.

Andrei-Pozolotin commented 4 years ago

Я имел ввиду

oh, thank god, now I understand, that is not me who does not understand :-)

скачивание и установка в песочнице с питоном

Andrei-Pozolotin commented 4 years ago

the rootfs nftables.conf should not be used

yes, this is the intent

vaminakov commented 4 years ago 
* it seems that you think that we want to install and run `qemu` container for the end-user

No, I dont think so

* this is not so: `qemu` is only relevant during unit tests, when unit tests are run either locally on developer machine or remotely on azure cloud

Okay, but I still doesnt understand why it need for tests :)

* you do not have to understand or implement that unit test, if you do not want to,
  but I challenge you to take your time and try to study and apply unit test to your proposed idea:

Okay, okay, no problem :) I understand how it works, but doesnt understand why needed. 

* and yes, actual end-user resources are still represented only by 2 files:

I see that. All is ok.

Andrei-Pozolotin commented 4 years ago

@vvl-rulez please review and test on live system #56

Andrei-Pozolotin commented 4 years ago

but I still doesnt understand why it need for tests :)

because proper testing of live initrd system can not be done with cgroups container, such as docker or systemd-nspawn, since initrd needs fully working udevd, and udevd is not virtualized by cgroups: https://github.com/systemd/systemd/issues/6562

Finally, Linux device management is generally not virtualized in containers, it's hence not possible to run udev in a container and have it manage devices. If you try the udev in the container will fight with the udev on the host for device ownership.

and therefore one needs hardware-emulated container, such qemu

Andrei-Pozolotin commented 4 years ago

@dvzrv David: please update PKGBUILD/backup to include extra *.conf PKGBUILD?h=packages/mkinitcpio-systemd-tool

Andrei-Pozolotin commented 4 years ago

@dvzrv David, @vvl-rulez Vladislav: again, thank you guys