Apparmor, SELinux, grsecurity on Qubes?

General Discussion
1

Hi,

what is about the security frameworks in Qubes? As I understand, they are not on board, but why?

Regards
qun

2

Anything not done by default is probably something that depends on the user’s unique situation (use case, threat model, etc.)

3

ok, that’s what I already thought about it. Thanks for the info!

4

grsecurity

this is new for me

5

AppArmor is on the way in 4.1 (still off by default in 4.1rc templates).
SELinux is tricky. Reported to work with some tweaks but nobody really supports it.
grsecurity, several somewhat successful attempts were made, but again, no one handles this stuff (nor did anyone evaluate if it is useful)

Not necessary. Maybe there is just lack of resources to support it properly.

6

Would you happen to know how AppArmor compares to SELinux? I’ve seen glowing praise for SELinux but nothing of the same sort for AppArmor. Though this doesn’t mean the latter is necessarily subpar, it’s still cause for concern.

As for grsec, it’s not free the last time I checked–do you know of a way for individual users to get ahold of it? Also, is it open and auditable? A closed-source kernel would raise eyebrows IMO

1 Like
7

AppArmor is somewhat simplified as compared to SELinux. However, SELinux policies are typically pre-configured by RedHat/Fedora, so the amount of stuff we need to manage ourselves is pretty small. GRsecurity is all different story. It is more like “generic exploit prevention”.

2 Likes
8

yea

If we haven’t already done that for a given thing, then it’s probably not something that would be appropriate for every user, or we’re still working on making it the default.

9

One of the things SELinux has been used for is to reduce attack surface inside the android OS. Basically they found that number of vulnerabilities discovered seemed to be proportional to the number of kernel calls available. When the kernel adds a new improved call to do something, the old way is kept for backwards compatibility. Since they knew they had up to date libraries that didn’t use the old kernel calls, they used SELinux to block them. (there was a youtube video of someone giving a talk on this somewhere. I don’t know where though)

So that’s one example of what SELinux can do.

AppArmor people will say AppArmor is “just more course grained” then SELinux. Of course they don’t mention what they mean by “Course grained”. One example of course grained would be a power switch. You disabled access to the legacy kernel calls by flipping the power switch. The same thing was accomplished, however now none of the other calls work, nor does anything else in the system.

Obviously AppArmor can be more fine grained then a power switch, but the point is that when they say “yes we can disable that, it’s just more course grained”, they mean that when they disable what you wanted, they will have to disable other things which will often disable the functionality of the program you were trying to run (meaning that you have to leave the feature enabled and not disable it if you are running AppArmor)

However, in practice, the real effort in using either is generating the profiles.

Also, there is a thread with someone successfully running SELinux (in a qube, not in Dom0), here:

Note that since the user isn’t supposed to be installing software in Dom0, that it should be possible to know which kernel calls are not needed, and they could do the same “kernel call attack surface” thing in Dom0 that android did. (assuming of course that they had unlimited time to do so)

3 Likes
10

@arkenoi @ddevz
Thank you both; that was educational especially for someone without the background like me.

It could be summed up as ‘Both do basically the same thing, but SELinux has more finesse–like a scalpel versus a sledgehammer’. I can see this as being a useability issue for unadvanced users like me though, so if I’m not doing anything special that requires special consideration, AppArmor seems like the one that won’t drive me insane.

SELinux support in Qubes would be a nice option though.

11

Is it possible to log all kernel calls for a few days trying out different things that would make different calls and then deny the ones that weren’t used?

Great explanation, by the way, thanks! Love the power switch analogy.

12

SecureDrop Workstation for Qubes OS has VMs that are hardened using a custom Linux kernel with the grsecurity patches, according to this 2020 post:

13

Yes, there are SELinux helper tools to do just exactly that.

14

The opposite direction of what you were saying, but one of the things that is supposedly common for people to do is set up a new computer with a new software install. Then turn on SELinux and run it in permissive mode. Then look at any SELinux errors in the log, enable those features, then run it some more. Repeat untill no SELinux errors in the log. Then finally put it in the mode where it will actually protect the system.

@arkenoi Do you have any example names of SELinux helper tools that people could start their searches on?

15

There are firewall management tools that manage IPtables rules trying to make it easier, the firewall management tools don’t implement their own version of IPtables in the kernel.

Realistically “AppArmor” should have just been made as management tools implemented through SELinux rules instead of creating a incompatible system from SELinux. If they had done that, then people wouldn’t have to go through this and could just focus on the actual security issues. Also programs wouldn’t have to have multiple profiles written for them (one for SELinux and one for Apparmor). I really wish they had done that.

3 Likes
16

iirc fedora included a tool that let’s you auto generate SELinux policy adjustments straight from GUI.

17

So there’s no real appreciable benefit from AppArmor striking it out on its own and creating its own system?

1 Like
18

Not to my knowledge.

19

I looked and found that fedora have debian have packages called “setools-gui”

Once installed, a gui program called “apol” is available.

Note: a non-gui tool that i see is “audit2allow” which is described as “generate SELinux policy allow/dontaudit rules from logs of denied operations” found in a package called “policycoreutils-python-utils” (on both OS’s)

@LadyPropane Want to start looking there and report back what you find?

1 Like
20

Definitely, but I don’t know if I’ll be able to make the time anytime soon. I’m following the thread, though.