Firewalld 1.0 Released With Big Improvements

[sdack]

Actually codecs are mostly implemented using the compiler's SIMD intrinsics. Ok, technically they are basically assembly instructions.

Many audio, video and encryption algorithms make use of assembly for obvious reasons. It is hardly a secret. But one can find other and more exotic algorithms, like the following malloc()-implementation that uses inline assembly:

http://locklessinc.com/benchmarks_allocator.shtml

It avoids race conditions by using assembly instructions and so creates a lockfree malloc()-implementation.

[sdack]

... that's not pertinent nor useful for the use cases that we are discussing here. ...

Oh, I am aware of your use cases. You like to switch your firewall manually. Probably like a l33t kid does: On and Off.

[jacob]

You are doing it again. You say trust was no replacement for security but you keep arguing like it was.

Security does not come from trust. Security comes from control. Without control do you have no power and trust is merely the first thing that you will lose. Trust is also not useful for starting a discussion on security, only distrust is. Trust is the fallout of good security, but also a weak substitute for not having absolute security. If there was absolute security then there would be no need for trust.

In reality security doesn't come from control, it comes from proof. To be able to prove, for example, a noninterference property, you need to chose an appropriate level of abstraction (in other words, axioms) that ultimately translate to trust; and you need to be able to model its behaviour to some axiomatic degree which in turn requires the right degree of control. But neither trust nor control alone can ensure security and in particular the idea that security is achieved by "simplicity" which in fact means extreme and error-prone complexity for the user is patently absurd.

[sdack]

In reality security doesn't come from control, it comes from proof.

This is not reality what you are talking about, it is called theory. Proof is only a form of control. By making a proof do you take control over terms, conditions and parameters and so create certainty over the correctness, and eliminate the need for trust. You may have started with a trust or a belief, but at the end of your proof will you have certainty, or you just have not learned what the point of a proof is yet.

Trust is a poor man's security.

[cueball]

ITT people coming up with obscure corner cases that explain why things could be bad... whilst showing that they have enough knowledge to come up with solutions to their particular scenario anyway. Technology has limitations, any abstration will have assupmtions and limitations intended to make life easier. We all work within imperfect systems and try our best to use them to meet our needs.

And trying to summarise the other random spurs of conversation:
- assembly can be faster, in certain circumstances, but its also a pain to manage for humans. It's literally why we invented abstracted 'languages' to represent intent & then an algorithym to make the assembly. The loss of efficiency is the trade off for managable code. Purist arguments that X is better than Y is akin to looking at a grey picture and arguing whether its black or white. Both are true and both are useful where it makes sense.
- language X is better than language Y is also asinine, they are tools. Use the tool that best works for you at the time. Hardly worth the time arguing a shovel is better than a spade when all you want is a hole.
- security is never absolute, and always compromises convenience. Your house isnt secure because it has a lock on the door. Your network isnt secure because you have a firewall. We build upon mostly-trusted structures to implement deterrants based on perceived threats. if someone asserts "my network is totally secure", you know they have more to learn.

Some people seem bent on trying to be negative. There's a new tool, it might have some limitations, they might be annoying for your specific use case, but lets look for the positives and try to help make it amazing. I like CLI but GUI's are often extremely useful.

[pal666]

When you are using a GUI or another app then you are not really using firewalld.

if those gui or app talks to firewalld then you need firewalld.

Or, when you do want to say so, then you also have to say you are using nftables, because firewalld is based on nftables. You cannot ride half a horse and pretend the other half had nothing to do with you.

just as i can say you use kernel even when you only talk to libc. yes, layering is how software works. and no, you can't say nobody needs libc because kernel is available

[sdack]

if those gui or app talks to firewalld then you need firewalld.

So, do you now agree that you are also using nftables when you use firewalld or are you still saying that you do not and that you would only need firewalld?

Do you know that firewalld is using nftables?

[jacob]

This is not reality what you are talking about, it is called theory. Proof is only a form of control. By making a proof do you take control over terms, conditions and parameters and so create certainty over the correctness, and eliminate the need for trust. You may have started with a trust or a belief, but at the end of your proof will you have certainty, or you just have not learned what the point of a proof is yet.

Trust is a poor man's security.

In your case it is obviously called ignorance. In practice noninterference proof is required everywhere real security matters, incl. in defense, smart cards, some banking systems and others. Your problem is that you don't understand what trust means. In security trust means simply what is assumed to be correct and out of scope of the proof, e.g. a certificate authority that will be considered ultimately correct and not verified any further, a key that we just accept, a device whose behaviour is not modeled (for example because it's not possible), etc. The crucial point is this: when something is "trusted" it means that it is a liability that can compromise your system. Having a precise definition of trust is an essential part of any serious threat model: if you can't tell for sure what you can prove and what you only assume (= trust) then you can't tell what the impact of a compromise would be, and you can't reason about mitigations or containment either. If you think that security is all about having the lowest level control possible then you are sorely mistaken, because in that case the trusted component is you, which is the worst case scenario possible.

[jacob]

So, do you now agree that you are also using nftables when you use firewalld or are you still saying that you do not and that you would only need firewalld?

Do you know that firewalld is using nftables?

I think you have long lost the thread of your thoughts if you ever had one. Anyone who knows the first thing about firewalld knows that it uses nftables so if you use firewalld, then firewalld uses nftables behind the scenes. The point that you have been mistakenly trying to make is that firewalld is useless because you can always do the same thing using nftables alone, which is not true. But don't worry, everyone who uses firewalld has your beloved nftables installed and active, they just don't interact directly with it because they don't need to.

[sdack]

In your case it is obviously called ignorance. In practice noninterference proof is required everywhere real security matters, incl. in defense, smart cards, some banking systems and others. Your problem is that you don't understand what trust means. In security trust means simply what is assumed to be correct and out of scope of the proof, e.g. a certificate authority that will be considered ultimately correct and not verified any further, a key that we just accept, a device whose behaviour is not modeled (for example because it's not possible), etc. The crucial point is this: when something is "trusted" it means that it is a liability that can compromise your system. Having a precise definition of trust is an essential part of any serious threat model: if you can't tell for sure what you can prove and what you only assume (= trust) then you can't tell what the impact of a compromise would be, and you can't reason about mitigations or containment either. If you think that security is all about having the lowest level control possible then you are sorely mistaken, because in that case the trusted component is you, which is the worst case scenario possible.

This is your interpretation of trust and most of it is correct. But the point was not what trust is, but what security is. Security is control, and control gives certainty. Trust comes from uncertainty and the lack of absolute security.