Yes, reviews.freebsd.org is also quite important and me, too, using it.
This is only due to recent developments some don't like and is more of an over reaction you can ignore.
Very pertinent point... If you're annoyed by that, the Forums do offer a way to ignore that user. There's also ways to report to mods and explain the behavior with concrete details and links.
Funny, considering that "Flatpak" support will bring many good mechanisms:
$HOME. chroot -n, however there are no means to control network access or to connect your user data without root.
. flatpak list --app | wc -l will show 37 apps installed on my desktop) I understand the frustrations and controversy -- but please, give me a tool that can do things i wrote about. If this tool will be more minimal and easy to tweak like everything FreeBSD -- thatd be awesome, besides we can just hypothetically sandbox stuff using the host userland and some nullfs magic, a thing that I am currently trying to implement. pkg(8) will be more than enough for actually aquiring software. Flatpak is a great piece of technology, and all the weird stuff with it was actually a collection of (sometimes very clever) solutions to Linux userspace fragmentation and software installation methods. I am actually dying to use FreeBSD as a daily desktop system because it is easy to set up, maintain and understand the parts of the sytsem. I mean that when you start setting up networking, disks, whatever -- it is so easy to do i was shocked the first time i did it. On Linux its literally unbearable to do something advanced except using it as desktop system. Dont believe me? Install Fedora Server and try setting up DNS for it to resolve .local addresses in your work environment, i dare you
. Another example -- GRUB settings. I love how FreeBSD does things, but I wish it did more things, because when FreeBSD does something -- it does it just right..
. Actually the whole post i wrote i wrote for saying two things -- flatpak isnt bad and i am obsessed with lack of rootless magic in FreeBSD.All I am saying is, instead of bashing some piece of tech because the implementation was weird, ask yourself, what problem did it actually solve in the end and how you can solve the problem better. Can't defend systemd like that though
I use rootless containers a lot for developing but I'm not a fan of flatpaks and don't use rootless containers in production. I don't like the idea of userspace networking for production, unless we import the NetBSD rump kernel concept to reuse the same kernel code in userspace and any performance issues are ironed out.I just wish rooless jails were a thing
I am not telling FreeBSD should adopt these exact technologies. I am telling that people behind it should evaluate why these technologies exist and what problem they had to solve. For the record here -- I dont like how Flatpak handles things such as storing runtimes and app dependencies, but it actually works in cohesive maner enough to be a flagship technology of "Desktop Linux" that i can recommend to people and not troubleshoot stuff, or for me -- again, easy and reliable sandboxing. While Linux has something, we dont have anything at all. We dont really need big userspace tools -- we just need the platform to provide these capabilities -- jail(8) utility is a perfect example, it is very usable and very minimal at the same time, rootless operation aside its the most flexible and adaptable solution out there, considering the new tech such as pkgbase and existing tech such as ZFS. Again, what I am trying to say is that Linux as a platform (kernel) has the means to solve a subset of problems that are impossible to solve on FreeBSD in its current state without resorting to insecure hacks. I want (sounds selfish
) to live in a perfect world, where this subset of problems can be also solved with FreeBSD the FreeBSD way.Rootless podman was sometimes a lifesaver, i should say that simple passthrough networking for rootless environments will be more than enough -- noone talks about using them in production. They are perfect for developing something or isolating user applications. User applications, not daemons or important services
. Fun fact -- systemd has podman support, right? However, they've changed the podman service file specifications, now its called "quadlet", and this "quadlet" can't be enabled for user containers, meaning you cant autostart them. Old format supports enabling though. Typical oversight of overengineered Linux userland.Considering portability across systems isn't a problem -- FreeBSD is FreeBSD, there are no different flavours of it, what about sandboxing
? We have Capsicum, yes, but it requires patching the software you are running, whereas you can turn any app into Flatpak without it knowing its a Flatpak. I believe Mac OS X has a more clever solution with MAC (Mandatory Acess Control) for resources -- meaning an app is an app and not an entire system in a bottle that sometimes gets poked.Yeah, exactly all the abstraction I'm looking to avoid with an OS running apps!
I'm thinking it's solving issues of security that could be better-solved with user-side education, or delegated elsewhere (Fedora with SELinux-default apparently doesn't use it for Firefox/unconfined but would sooner seek Flatpak sandbox support for it on-top of Firefox's own sandbox, general Linux permissions... and SELinux). It's bulking up and slowing down my base installs for stuff tailored for cloud and users afraid of booting from USB and disk wipes.All I am saying is, instead of bashing some piece of tech because the implementation was weird, ask yourself, what problem did it actually solve in the end and how you can solve the problem better. Can't defend systemd like that though
I agree. At the point you are running untrusted, malicious software on your system, you have a personal issue related to your tech-savvyness. No packaging system can prevent malware from overtaking a system.
It's the other way around: Podman supports systemd. I myself don't use quadlets and prefer docker-compose, which podman can use.Rootless podman was sometimes a lifesaver, i should say that simple passthrough networking for rootless environments will be more than enough -- noone talks about using them in production. They are perfect for developing something or isolating user applications. User applications, not daemons or important services
It depends if the packaging system contains a sandboxing solution. Jails in FreeBSD are nice because they're first-class citizens in the OS. Containers in Linux, OTOH, are abstractions based on namespaces & cgroups that are hardened later with SELinux/Apparmor + Seccomp + Capabilities, etc. Jails are hardened out of the box.
Even if it can protect you, it still isn't best practice to be running weird crap on your system.
FreeBSD doesnt need Flatpaks, what I mean is that FreeBSD need some tech that made Flatpaks possible -- the only missing piece being rootless jails. We did conquer the layered nature of container stuff on Linux.
Look, we have www/firefox without any sandboxing, and this is very important in the day and age of bloated and potentionally dangerous Javascript, jailing the firefox to mitigate some subset of issues would mean two things:Yeah, exactly all the abstraction I'm looking to avoid with an OS running apps!
. Modern desktop software is very big, and I believe it is up to modern desktop platforms to manage all that.Software can be malicious not because it was designed as that, again -- Firefox and Javascript. On Windows, there were literal RCEs in farily simple messenger Telegram. Was it interntional? Not really. Can you think of Telegram as literal malware? Not really too.
Yeah, Linux's "under the hood" implementations are usually very messy and hard to maintain without some arcane knowledge of tool-specific syntax and conventions. But who can rival it?
Thanks to FreeBSD jail(8) magic and it's limitless nature, you can actually isolate the software without resorting to having another copy of OS stored somewhere, and said software could be installed with pkg(8). I've done that, and I should probably write about it on forums. You can literally use your host / as jail root (though nullfs-moutned somewhere else) and then nullfs/tmpfs to allow/deny acess to filesystem. Everything else is standart jail magic -- networking, securelevel, whatever. I should probably finish writing the script i made just for that and publish it somewhereYeah, exactly all the abstraction I'm looking to avoid with an OS running apps!
I'm thinking it's solving issues of security that could be better-solved with user-side education, or delegated elsewhere (Fedora with SELinux-default apparently doesn't use it for Firefox/unconfined but would sooner seek Flatpak sandbox support for it on-top of Firefox's own sandbox, general Linux permissions... and SELinux). It's bulking up and slowing down my base installs for stuff tailored for cloud and users afraid of booting from USB and disk wipes.
.Actually we have another potentional solution for isolation and all that -- Capsicum. In it's current form it requires patching the application, but what if Capsicum could be used externally without app's knowledge about sandboxing at at all... There was a project like this (link), but it's development stopped and it had some issues, if I remember correctly. Also, again, modern MacOS -- uses its own MAC-based solution (SELinux is MAC-based solution) to manage app permissions. Rootless jails are still my wet dream though -- they are just for user app isolation, but whatever
.
. And after some time it wanted 
$DISPLAY set in a TTY session, what an insane state of things -- just to fetch and unpack a bunch of files it is required to have dbus session set up properly. What kind of package manager is this 
.
.).
chroot -n) and new mac_do() platform capabilities, by the way.Oh yeah, I mean you now have two ways of doing jailed applications:
.From what i've seen there are multiple things that should be implemented for that:
INSTALL_AS_USER environment variable on host and pkg -r $our_chroot chroot -n into the new chroot (providing you enabled the necesary sysctl for it)Just try Poudriere sometime (if you have enough metal to play with something like Poudriere). Once you get a handle on how it works, it may answer a LOT of your opinions and questions about pkg on FreeBSD.
Oh yeah, I mean you now have two ways of doing jailed applications:
I dont remember if I mentioned this or not, Podman containers on FreeBSD arent some dark magic -- they just ported OCI layering stuff for providing the container runtime-userland-root-hierarchy, and adapted networking stack. The running part uses the same standard jail capabilities -- just launch a podman container on FreeBSD -- it's a jail, visible by jls(8) utility and you can run stuff with jexec(8). Again -- the only special sauce things that Podman has on FreeBSD are networking and managing OCI layers, they are the same jails as with jails managed by iocage, ezjail, jail(8) utility, and many other tools. May someone correct me if I am wrong though about Podman on FreeBSD internals -- maybe theres something else to it besides gluing together OCI layers into a chrootable environment and doing magic with networking. They are still jails
- Jails made with pkgbase
- Podman, if you need compatibility with OCI stuff
Funny, considering that "Flatpak" support will bring many good mechanisms:
About Wayland -- Wayland is actually better on FreeBSD for the simple reason being the inability to run X11 without root on FreeBSD. Fun fact -- Xlibre repository had some pull requests for allowing libseat support, but whatever.
- Rootless Jails (because Flatpak uses user namespaces)
- Rootless mounts (how will you actually setup the "jail" environment and have access to user data)
- Portals -- aka dynamic access to resources when user agrees to allow an app something (for example, Telegram Flatpak doesnt have any FS permissions at all, however when i use the file picker, only the file i select to upload goes visible to Telegram)
Flatpak's portability "soluition" is mostly redundant on FreeBSD due to the fact that we dont have distros, meaning one of the core advantages of Flatpak (same runtime userland) is irrelevant. However, Flatpak also utilizes portal system for resource access and provides the end-user with mechanisms to control resource access. It is very convenient to have means to control network or filesystem access using config file or even GUI. And it all runs without root.
Also you could install apps in user scope, meaning the whole app will be installed somewhere in$HOME.
pkg(8) can do that too, and we have rootless chroots, which ive tried, you can run an entire FreeBSD userland inside your homedir and install packages in it with some pkg environment variables dark magic and withchroot -n, however there are no means to control network access or to connect your user data without root.
I saw somewhere that some mech behind Flatpak (bubblewrap?) could be ran as suid on systems with user namespaces disabled, but eh......
Also would be funny and cool if someone actually ported Flatpak and used it with Linuxlator. If we throw the task of actually running apps (again, we dont have user namespaces or any other means of managing jails and their mounts without root), the whole fetch+install process of Flatpak is doable even now (look at sysutils/podman).
It will actually be a big win -- compatibility with Linux desktop stack routines is a net positive for everyone. A dumb way to migrate to FreeBSD -- users might think "oh, it supports Flatpak too, I better check it out". Imagine the moment when they realize later that FreeBSD is not some Linux distro and some program that uses low-level stuff actually fails on them after spending so much time using the system
As a (if you could say that) Flatpak user (flatpak list --app | wc -lwill show 37 apps installed on my desktop) I understand the frustrations and controversy -- but please, give me a tool that can do things i wrote about. If this tool will be more minimal and easy to tweak like everything FreeBSD -- thatd be awesome, besides we can just hypothetically sandbox stuff using the host userland and some nullfs magic, a thing that I am currently trying to implement. pkg(8) will be more than enough for actually aquiring software. Flatpak is a great piece of technology, and all the weird stuff with it was actually a collection of (sometimes very clever) solutions to Linux userspace fragmentation and software installation methods. I am actually dying to use FreeBSD as a daily desktop system because it is easy to set up, maintain and understand the parts of the sytsem. I mean that when you start setting up networking, disks, whatever -- it is so easy to do i was shocked the first time i did it. On Linux its literally unbearable to do something advanced except using it as desktop system. Dont believe me? Install Fedora Server and try setting up DNS for it to resolve .local addresses in your work environment, i dare you
All I am saying is, instead of bashing some piece of tech because the implementation was weird, ask yourself, what problem did it actually solve in the end and how you can solve the problem better. Can't defend systemd like that though
I just wish rooless jails were a thing
Hi
!
podman run -v -it ~/development:/mnt:Z almalinux:10 bash and ill have a "jailed" environment with AlmaLinux, in which i can install packages, set up users, I can even access the internet (my ethernet interface is shared with the container). Now, even if i mount /etc/ssh/ into that container that i ran as root, i still cant read stuff in it -- root inside the container and root on the host arent the same thing. On the host, dnf install mariadb or even cat /etc/ssh/sshd_config commands will be seen in top(1) utility to have my user, not root or whoever else. To the host, all the processes inside this "jail" are mine, not root's or anyone elses, no matter the top(1) output inside that "jail".Thank you, didnt know that. I knew that Podman is just a manager of many things, and I even saw some QEMU emulation and libvirt(?). Didn't know there was another player on the market.
I am not sure how this relates to the topic of software confinement. Please, explain in response to what statement of mine you offer me to try Poudriere.
As unprivileged, non-root user.
You mean cascaded (stacked) jails, that bottommost one is created by root for specific non-root user (or group) and the user(s in the group) creates jails in it by him/her self?
I think we'd need some kind of design document to discuss the concept. For instance, in Linux rootless podman is an approach to set up systemd to allow users to interact directly with systemd without root privileges. I think what we need here is to review what kind of exposures might there be should we choose to make /usr/sbin/bhyve* setuid root or better, capsicumize bhyve.