FreeBSD Security Complexity

C

CreativeGPX

I'm still pretty new to FreeBSD and most of my Linux security experience is just setting basic file permissions and firewall settings. In reading through the FreeBSD Handbook though, I remember being very struck by the contrast between how clean and simple the system as a whole aims to be and how complex the set of security systems seems to be.

For example, Unix file permissions, file flags, ACLs and (possibly?) MAC all seem to have some overlapping or, at least, highly related functionality. The OS comes with PF, IPFW, and IPFILTER and altq and dummynet, which all seem to have related functionality. Then there are a bunch of other systems like MAC, jails, chroot, process accounting, resource limits and auditd. I'm not necessarily saying all of these should be one master security entity, but it seems to me like the amount of distinct and perhaps competing philosophies and interfaces for setting security makes it a lot harder to comprehend the security setup of the system which is both annoying and dangerous. For example, it seems rather difficult for an admin to see all policies (all different permissions, quotas, logging, etc.) related to a particular system action being done. Instead they have to go to a bunch of different, perhaps competing, systems? This, to me, seems to make it likely that an admin might not realize certain loopholes or restrictions if it's all so spread out.

Could anybody here speak to the design decisions that motivated this and how well you think it works in practice to have so many separate security systems?
 
CreativeGPX said:
Could anybody here speak to the design decisions that motivated this and how well you think it works in practice to have so many separate security systems?
Click to expand...

FreeBSD serves more for the craftsman and less for the artistic approach.

The craftsman got a very well understanding of what he wants to achieve, then he looks into his toolbox and picks the tools which serve best his goals. Craftsmen who stay at the narrow road achieve always something useful with their tools they find in the FreeBSD Security toolbox.

The artist looks into the toolbox thinking about what incredible art he can make with the tools today -- something like a Firewall + Triple NAT that in addition can sing and dance. Only very good artists can make FreeBSD into something useful, others fail miserably.
 
obsigna said:
The craftsman got a very well understanding of what he wants to achieve, then he looks into his toolbox and picks the tools which serve best his goals. Craftsmen who stay at the narrow road achieve always something useful with their tools they find in the FreeBSD Security toolbox.
Click to expand...
So you are suggesting that the philosophy of FreeBSD is to provide many approximations/approaches of solutions to the same problem all packaged within the base system and then let users choose which ones to ignore? This seems kind of unlike my experience in other areas of FreeBSD where a clean, minimal approach was chosen and if you want alternative solutions you can go make one from ports.

In the case of choosing between nothing, chroot, jails and (possibly) bhyve there is a truly distinct behavior and feature set so it makes sense to me to have those each included as separate entities.

With file permissions or firewall/packet-shapers, it seems that a unified design wouldn't have to prevent the craftsman philosophy you mentioned. If the most expressive file permission system and the most expressive network flow manager were chosen, then you'd basically end up with one configuration you could set which would invoke whichever tools the craftsman you mention wanted and ignore whichever he didn't. If you have a very expressive permission system, you could use it like simple Unix permissions or be more verbose which would invoke other systems. The main difference though would be that those permissions would be entered, retrieved and managed by a common entity which would make it easier to track and design them. Similarly, a very expressive system for describing network flow rules could have each rule that the user writes invoke different tools. The craftsman you speak of remains, being able to invoke or ignore the various tools that the firewall could call, but now all of the rules are in one place. If you want to understand your network flow there is exactly one place that you go to and you are guaranteed to see all of the factors there. Unifying the language, the config file or the admin-facing console command does not have to mean that choice of how to solve a problem goes away. It just means that all choices about solving that problem are represented and managed in a common area.

I don't mean to be snarky here. I'm just trying to figure out if all of this is a brilliant design choice or an artifact of the realities of backwards compatibility. (I've recently been reading a lot of Microsoft blogs on their creation of Windows. The amount of times that they knowingly turned down great design choices they came up with in order to maintain backwards compatibility was really eye opening.)
 
CreativeGPX said:
obsigna said:
The craftsman got a very well understanding of what he wants to achieve, then he looks into his toolbox and picks the tools which serve best his goals. Craftsmen who stay at the narrow road achieve always something useful with their tools they find in the FreeBSD Security toolbox.
Click to expand...
So you are suggesting that the philosophy of FreeBSD is to provide many approximations/approaches of solutions to the same problem all packaged within the base system and then let users choose which ones to ignore?
Click to expand...
I was not suggesting anything. I am only comparing the software toolbox of FreeBSD with the toolbox of a well equipped craftsman.

CreativeGPX said:
This seems kind of unlike my experience in other areas of FreeBSD where a clean, minimal approach was chosen and if you want alternative solutions you can go make one from ports. ...
Click to expand...
Even in my hobby craftsman's toolbox I got 3 kinds of hammers, more than 10 types of screwdrivers, 2 types of drilling machines, 2 solder irons, etc. Anyway, I am capable to choose the right tool to get the job done. And I never came even close to the idea to complain to the management of hardware stores about them supplying hundreds of other kinds of screwdrivers, some of which I never saw.

Back to the various FreeBSD software toolboxes, now I suggest something: Exactly understand the goal and only after that choose and employ the tool. Beginners may want to explain their goals here and usually receive recommendations for a well chosen core of tools to achieve it.
 
FreeBSD tends to have more than one way to do something. A lot of that is that just due to the length of time it's been around. New methods are added, but are either compatible with the old methods, or exist alongside them. Sometimes the older implementation is adequate for most cases, or has less overhead, and remains in the base. IPF was nearly removed lately, but a last-minute effort brought it back. Agreed that it's kind of silly to have three firewalls in the base, although it's an abundance of riches compared to other systems. It does make things less simple by offering the user multiple choices rather than only one way to do things. Ideally, the Handbook will show the most common method to use.
 
obsigna said:
Even in my hobby craftsman's toolbox I got 3 kinds of hammers, more than 10 types of screwdrivers, 2 types of drilling machines, 2 solder irons, etc. . . . And I never came even close to the idea to complain to the management of hardware stores about them supplying hundreds of other kinds of screwdrivers, some of which I never saw.
Click to expand...
But you wouldn't generally wear 3 hammers on your standard tool belt. Your probably have one and then if you needed a special hammer in a special case you'd go to storage (toolbox or hardware store, i.e. pkg or ports) and get that special hammer. Then again the metaphor breaks due to the fact that, once configured, these systems act on their own. So you have to check each individual system to see how it's set up. That'd be like having to inspect each of your hammers to figure out if a nail is being hammered rather than just looking at the nail.

obsigna said:
Back to the various FreeBSD software toolboxes, now I suggest something: Exactly understand the goal and only after that choose and employ the tool. Beginners may want to explain their goals here and usually receive recommendations for a well chosen core of tools to achieve it.
Click to expand...
wblock@ said:
FreeBSD tends to have more than one way to do something. A lot of that is that just due to the length of time it's been around. New methods are added, but are either compatible with the old methods, or exist alongside them . . .
Click to expand...
I don't doubt their unique contributions. It just feels greatly at odds with the Unix/BSD value of simplicity like, Doug McIlroy's saying, "We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design." It's kind of funny. In some regards the community is so intently focused on being small and bare bones and including as little as possible and being extremely methodical about not spreading our programmers too thin. Then in other areas, this happens and with pride. Before reading the handbook I'd expected that FreeBSD would include one elegant way to do each thing and point you to ports for other great tools that fit more specific scenarios.
 
I would like to point out that I don't really like Linux, I don't prefer Linux over FreeBSD and I don't think Linux does a better job of this task. I don't think it matters how FreeBSD is doing here compared to Linux. My comments are just about how FreeBSD is doing with respect to what I understand FreeBSD to be.

As I said, the intense resistance I see on these forums from people about increasing the amount of things in the base, the amount of things that need to be maintained and the amount of things that need to be installed seems to be contradicted in this case with the amount of approximations of the same solution. The main reason things stand out isn't because it's especially complex, it's because the rest of the OS design is full of things that are brilliantly simple. In the global picture (compared to Windows, Linux, Mac, etc.) this may not be all that bad, but in the context of FreeBSD it really stands out. The varying approximations of a good answer to permissions or network traffic handling is just plain ugly. I know that that level of complexity is present in Windows and in Linux in these areas. I was just hoping that the typically simple FreeBSD would have a brilliantly simple solution here because I think it's definitely possible. Perhaps everybody is just stuck victim to legacy and compatibility.

Now your questions:
I deal with Linux by necessity and I choose distros on a case by case basis but, where I'm not seeking out some highly specific configuration like ultra small or security/recovery focused, I usually just pick something that has a big helpful community and/or a lot of available software to add. However, I don't want to deal with Linux and I don't want to choose distros. I like the order associated with BSDs, Windows and Mac and I don't like Apple. So here we are. I aim to use Windows and FreeBSD and that's what I've been doing.
 
CreativeGPX said:
Now your questions:
I deal with Linux by necessity and I choose distros on a case by case basis but, where I'm not seeking out some highly specific configuration like ultra small or security/recovery focused, I usually just pick something that has a big helpful community and/or a lot of available software to add. However, I don't want to deal with Linux and I don't want to choose distros. I like the order associated with BSDs, Windows and Mac and I don't like Apple. So here we are. I aim to use Windows and FreeBSD and that's what I've been doing.
Click to expand...

The difference between Linux and FreeBSD (or any BSD for that matter) is there is no distro (save for PCBSD which is the exception that proves the rule).

In the realm of FreeBSD, the human operator tweaks the system to his liking and does not rely on ready-to-use solutions provided by a third party.

This is why the FreeBSD documentation is simply outstanding.

EDIT: GhostBSD, like PCBSD, is a desktop project built on FreeBSD.
 
I sympathize, as I think this does contradict the spirit of BSD shown in most other areas of the project. It sounds like you may prefer OpenBSD. One of the GSOC 2014 students this year is working on bringing Capsicum to that project. Theo de Raadt has criticized this issue in FreeBSD, namely that there are plenty of security features, hardly any of them turned on by default. (eg, here.)

That's not to say that I dislike FreeBSD, I just wish PF was updated and FreeBSD better integrated the great features that are already available, rather than just offer them.The stack protector is still not on for ports by default, for example. There are three firewalls available in base, (none turned on by default), but no sudo.

obsigna said:
FreeBSD serves more for the craftsman and less for the artistic approach.
Click to expand...

Except that doesn't seem to be true for most areas of operating system design for FreeBSD, which is what the thread author pointed out. In my experience, FreeBSD often tries to do one thing and to do it well. Why the exception here? Where's Xen Dom0 support as an alternative to bhyve, for example?
 
You must log in or register to reply here.
Back
Top