For some time, I wanted to create a couple of “opinion pieces” on the wiki. Although it isn’t the perfect place for subjective material, I believe it is helpful to have a short page that summarises something that is being brought up again and again on here. Instead of explaining it, we can simply send a link which gives a well-worded, thought out response to something.
One thing that is bothering me for a long time is that users install random software on their systems. They can of course do that - it is theirs, but that does not come without any downsides. Very often additional software on here is in a beta state, not peer-reviewed and most likely abandoned and will never receive updates. We get loads of support cases because of that, and people risk breaking the integrity and security of their systems and networks. Don’t do it unless you know what you are doing is the point I want to get across. However, most people will now assume that they know what they are doing, that is why they need more explaining about the consequences which I wanted to collect on this page.
I think it’s a good idea to have a few critical messages like this in the wiki.
This one I think is especially important with regard to a firewall. It’s short, so it should be read, but very clear. People can then make their own minds up about it but they can’t say they didn’t know.
Hi,
I support this also.
For some users it explains why the core developers aren’t eager to check each possible Linux program for compatibility with IPFire, too.
Good idea, BUT pakfire needs a small window that explains what each add on package does.
Thus when the user selects a pakfire package a small blurb of what the package does should appear.
The user can then decide if it will do what he needs and then maybe not add in some 3rd party junk.
I can’t follow your thought.
Surely it would be nice to have a short description of the addons.
But most are described in the wiki ( each member of the community can enhance this ).
So I think it is the same effort as reading the documentation at the 3rd party ‘junk’.
Users not reading either can’t be hindered to install those ‘enhancements’.
My understanding of Michael’s Wiki page was that 3rd party software means software that has not been provided by IPFire and is not installed by pakfire but is supplied as a foobar.ipfire file. The .ipfire file installs the software as a binary plus assorted other files where the source code will never have been reviewed by the IPFire team. That I think is exposing yourself. You are then totally trusting the person who has provided that .ipfire file to be a good player. Even if you trust the person supplying who created the file you also then have to be certain you are downloading it from a non-compromised website.
The add-ons installed via pakfire have been compiled by the IPFire team and are cryptographically signed which pakfire checks is correct.
It is certainly correct that you also must decide if a particular add-on is appropriate for a firewall in your specific situation.
Over time add-ons are removed from the system, either because they are no longer considered to be appropriate to have on a firewall under any circumstances or because the add-on is no longer being kept up to date by the originator or any interested party and is likely to have security vulnerabilities.
Perhaps some thought could be given to running untrusted software in a virtualised context that is locked down. Something like docker containers that can be pulled into the ipfire device and strictly managed from the ipfire OS, yet the software can do what it wants within its own little docker container.
I think that is a far superior option to just banning anything but approved code because it puts a burden on you guys to approve everything that goes on the device for starters, and it limits the potential/functionality of the device.
Surely a way for us to import docker containers (or even just one container that we can run all the software we desire in) that run the software we need (filebeat as an example in my case) might be a great way to do this. Then you could enforce things like read only access to the host OS from the docker container etc. It would also allow for Firewall rules specifically for the docker container, so you could just open one or two ports for whatever services are running in the docker container and close the rest, nothing else can come in or go out from the docker container. I think that modern virtualisation technologies could bin the pakfire system with something significantly more flexible, that enables users to do the tasks they need with their UTM, without relying on a nod from a developer first. Surely that is a far more sane approach than just blocking everything?
This would also ease the burden on you guys, because currently I see the dev mailing list is pretty well flooded with people updating pakfires!!! And mission critical bugs like this one go unspoken of!
This is what the big players are doing nowadays, they are creating virtual contexts for “untrusted” code to be execute in, that is sandboxed from the OS actual.
I think you are unecessarily burdening yourselves being god for anything that goes on the device. Put docker on the ipfire, harden it, allow whatever the hell one wants to run in that hardened docker context, job done. And it will free you up to actually fix problems instead of updating pakfires for days.
At the moment I’m building filebeat from source and i use git to pull it down onto my ipfire device, and i am using init.d to run it as a service. Am I owned? I do not believe so.
If I can’t build from source and my only option is to download the third-party binary, if I need to do that task then I will download that binary. It’s not my fault ipfire doesn’t have a virtualised sandbox for untrusted code. To suggest I am instantly owned is merely your opinion, and not necessarily a fact.
“We would like to urge you to never ever do this. We spend so much time on auditing every single line of code that goes into IPFire; we pick certain versions of software because it is most compatible; we patch software to make it work better in IPFire; and in the end we cryptographically sign all releases so that no third party can change any of this and inject anything unwanted.”
In summary, all these things you say can be mitigated with a docker container running on device for untrusted/untested code. It will even provide isolation from incompatibilities. We’ve had the ability to run bad code from secure environments for years man. If you are spending time auditing every single line of code for every single add-on (and I’d suggest that’s not the case in reality), that’s time wasted.
Do not download any packages from the Internet; they will break your system sooner or later and you will never receive updates for them ← What you mean is, “You will not receive updates via ipfire updates” which is obvious and expected if you are sideloading and not using pakfire. Of course the onus is on me to provide an update mechanism, on another machine I can run a cronjob to pull the code and build it and commit it to a git repo, on the ipfire I have a cron that pulls the git repo to update the binary. I also run things like a DNS blocklist that ipfire doesn’t support. I have cronjobs that pull the blocklists, stuff them into unbound etc. etc. I think the nazi status of “you can only run approved things” is dead and gone since at least 2015.
Please reconsider your thinking. Pakfire is DRM aimed at restricting the user to what you approve based on a false perception that you know best.
How is that any different to us totally trusting that the people making IPFire are being good players? I think you guys are looking from the inside out, rather than the outside in. For the average user they would have to apply the same risk weighting to the IPFire devs as any other software. There is no way possible that you can simply say that IPFire devs are more trustworthy, therefore it is so. This I think, is one big shortfall here. You guys are operating on the assumption that IPFire is good and everything else is bad. We, the users external to IPFire have to operate on the assumption that EVERYTHING, IPFire included, is bad, and so we make our own risk assessments for each piece of software we use based on that.
If we can blindly run what the IPFire devs give to us, how is that any different to blindly running anything else? We should be allowed to determine our own risk appetite and build and deploy what we see fit based on that appetite.
As IPFire is open source software you are at liberty to do anything you want with it. You can even fork it and create your own firewall and include whatever you want in it.
I understand, and it is a great thing. But the issue here is the deeming of anything that isn’t approved/ crypto signed by IPFire for installation, to be bad. I strongly believe that to be a false statement. I think it’s totally fine to run the pakfire DRM system for people that do want to put complete trust and faith in the IPFire team, and wish for their binaries to be vetted/signed by them. No problem with that. However the restrictions and to then claim that it is bad for one to put third-party binaries on their IPFire because they haven’t been vetted by IPFire, I do not agree with that at all.
There should be a mechanism for people average users to make their own risk assessment on a case by case basis, and install what they need to get their job done, without having to resort to standing up a dev environment and all that stuff and being wrongly told that they are compromising their device.
They may be compromising their device. But they may also not be. And what risk does a compromised device pose to them? This question can only be answered by them. We all have to make our own risk assessments to suit our environment. The default “trust us because we’re awesome, and don’t trust anything else because they’re not us” is not a good model, it sucks in fact.
And not to throw shade at yas, you guys actually are awesome and you make a great platform. And I certainly don’t think or suggest that you code with bad intent. I just think there needs to be a different thinking on this issue is all, because if you think about it, hardware manufacturers could start doing what IPFire does, they can say “You can only run our OS that is signed by us because we are awesome and we only do right by the user, all other OS is bad”. That exists, it’s called iOS and many people get angry about it. IPFire is essentially being Apple, locking people into what they approve only and saying anything else is bad. And I don’t think that’s your intention, but it is exactly what it is.
Yeah, containers provide no security whatsoever. That is not isolation against anything and so I would not at all consider that an option to run any third-party software - especially when it is (as you suggest) untrustworthy.
Sandboxing has never worked anywhere. If they big players do this and you like it feel free to buy their products. We don’t do this because it provides a false sense of security which is exactly what we are trying to combat here.
There is no such thing as hardened Docker. It is literally mutually exclusive because the “feature” of a container is that it is lightweight - i.e. there is nothing between the code running inside it and the host OS.
And, once again, we allow people to do whatever they want with their systems. You can compile Docker yourself and install it; you can write software that sings Happy Birthday and install it on your firewall if you wish. This is not possible with commercial (i.e. non-free) software.
We do not seek to limit any functionality at all. Your system is yours and you can do whatever you want with it. We do not own it.
What we own though is IPFire, the distribution, which has ways how certain software is becoming a part of it. That is a democratic, peer-reviewed process and by definition custom modifications are not that.
The “burden” I want to take away from this community is to provide support for such modifications.
Yes, that is what we do because it is important. It might be that you ran into a bug which is very important to you, but there is more than one ticket open at this time and we prioritise them by severity and how likely it is that people are affected by them.
If you have a problem, you can fix it and you should submit a patch then for everyone to get your fix. If you cannot find a fix, reach out to someone who can help you.
But I do.
Exactly. This is not meant as in “someone has full shell access to your system”. I said that your system is being compromised which means that something is on it that should not be there. You are free to do so, but I will simply call it that.
Cool. You are an expert on this then. I had no idea that you alone could do the job of all of us so much better than we could.
I can only point out that IPFire has an excellent track record and so I would assume that we are doing some things right.
Yes, this does not mean that there are no updates being provided by the third-party authors. But let’s face it: Nobody will manually install them all of the time. We rather see that people run the first version they could find for years. So I think it is fair to say that that software is virtually never being updated.
First of all, I am taking this as an abusive comment. Secondly, you should absolutely read what I was saying: You can run whatever you want.
There is no DRM. You are just being unhappy that we do not fix your bugs first and that we do not provide Docker. Guess what? Nobody is doing my job for me either… I have to do it myself.
Yes, we do. It is called a chain of trust. If you wouldn’t trust us, you wouldn’t run IPFire. And so we make sure that there are technical means in place so that you can be sure to run software that is coming from us. If you decide to not trust us, you should uninstall IPFire and use something else.
This is how this works. You trust Microsoft, you trust Amazon, you trust many parties - if you want it or not.
Adding extra software means that you trust someone else as well. That is okay, but that does not mean that I am trusting the same people you do.
However, you are acting as a bad player. You call pakfire a DRM system which is factually wrong because nothing is stopping you from installing anything else on your system apart from that wiki article which is asking you to think about it before you do.
You are also calling people Nazis and you approach this whole debate wrong a very weird angle. You don’t care for what literally every response to your posts are and you are turning it upside down.
You know how ridiculous that is what you are saying? IPFire is free software? How can that possibly be locked down?