No what I said isn't about user registration; it's about adding these to the docker-compose.yml:
read_only: true
user: 6969:6969
to prevent running as root and making the file system read-only. The API needs to be exposed without a VPN or other proxy login since my parents' can't handle that, so if I was able to implement these recommended security steps I'd feel like I could open up the container to the internet at large without too much risk.
It would be also ideal if I didn't have to give the container (but not a deal-breaker):
cap_add:
- CAP_SYS_ADMIN
- CAP_SYS_CHROOT
as the issue also states is required for the headless chrome scraper browser.
I am using it internally now and it's really good, but to open it up for my parents (which I think they'd dig) I'd definitely want these security settings on without major issues. Linkwarden is an internet-facing application so these recommended security practicies are in its wheel-house, feature-wise, as well.
As always you store data you want to keep in the volumes section.
With read-only you prevent new binaries from being added in the image space. You can add ânoexecâ to your volumes/tmpfs preventing binaries to the areas that are writable. Then ideally you are using an image with minimal surface area (e.g., only sh and the exact binaries needed to make it go) and itâs very secure! Itâs still plenty secure without a minimal image.
So I have mine running in a podman quadlet. It runs as root in the container but it is unpriviledged. Mine has NET_ADMIN and SYS_MODULE but I honestly canât remember why⌠SYS_ADMIN seems extreme though
Sure thing, Iâll edit this reply when I get back to my computer. Just note that I also have a tailscale and nginx container in the pod which are not necessary.
Youâll see my nginx config which reverse proxies to the port the service is running on. On public servers I have another nginx running with SSL that proxies to the port I map the podâs port 80 to.
I usually run my pods as an unpriviledged user with loginctl enable-linger which starts the systemd --user services on boot.
All that being said I havenât publically exposed linkwarden yet, mainly because itâs the second most resource intensive service I run and I have all my public stuff on a shitty vps.
glizzyguzzler@piefed.blahaj.zone â¨2⊠â¨days⊠ago
No what I said isn't about user registration; it's about adding these to the
docker-compose.yml:to prevent running as root and making the file system read-only. The API needs to be exposed without a VPN or other proxy login since my parents' can't handle that, so if I was able to implement these recommended security steps I'd feel like I could open up the container to the internet at large without too much risk.
Per this issue https://github.com/linkwarden/linkwarden/issues/799 it seems like there's a lot of steps to take to get these settings to work.
It would be also ideal if I didn't have to give the container (but not a deal-breaker):
as the issue also states is required for the headless chrome scraper browser.
I am using it internally now and it's really good, but to open it up for my parents (which I think they'd dig) I'd definitely want these security settings on without major issues. Linkwarden is an internet-facing application so these recommended security practicies are in its wheel-house, feature-wise, as well.
Hope that helps clear up my comment!
daniel31x13@lemmy.world â¨2⊠â¨days⊠ago
Oh I see, thanks for letting me know! Yes thatâs actually requested and weâll be getting to it sometime.
glizzyguzzler@piefed.blahaj.zone â¨2⊠â¨days⊠ago
Great to hear! Itâs seriously slick and âjust worksâ. With those security features up you can tout them on the cloud offering too :)
Lem453@lemmy.ca â¨2⊠â¨days⊠ago
How would you add new links if its read only?
glizzyguzzler@piefed.blahaj.zone â¨2⊠â¨days⊠ago
As always you store data you want to keep in the volumes section.
With read-only you prevent new binaries from being added in the image space. You can add ânoexecâ to your volumes/tmpfs preventing binaries to the areas that are writable. Then ideally you are using an image with minimal surface area (e.g., only sh and the exact binaries needed to make it go) and itâs very secure! Itâs still plenty secure without a minimal image.
Lem453@lemmy.ca â¨1⊠â¨day⊠ago
Couldnât the attacker just drop a dangerous binary into the data volume then?
somethingsomethingidk@lemmy.world â¨2⊠â¨days⊠ago
So I have mine running in a podman quadlet. It runs as root in the container but it is unpriviledged. Mine has NET_ADMIN and SYS_MODULE but I honestly canât remember why⌠SYS_ADMIN seems extreme though
glizzyguzzler@piefed.blahaj.zone â¨2⊠â¨days⊠ago
Care to share your quartet? Iâm just getting into the quads with trixie out - and I havenât gotten this working yetâŚ
somethingsomethingidk@lemmy.world â¨2⊠â¨days⊠ago
Sure thing, Iâll edit this reply when I get back to my computer. Just note that I also have a tailscale and nginx container in the pod which are not necessary.
Youâll see my nginx config which reverse proxies to the port the service is running on. On public servers I have another nginx running with SSL that proxies to the port I map the podâs port 80 to.
I usually run my pods as an unpriviledged user with
loginctl enable-lingerwhich starts the systemd --user services on boot.All that being said I havenât publically exposed linkwarden yet, mainly because itâs the second most resource intensive service I run and I have all my public stuff on a shitty vps.