Full-Policy integration for Whonix/Kicksecure - And also everyone else

[monsieuremre]

Hello good sir. Full policy is here. Fresh and ready to eat. Doesn't break one thing, and is rather restrictive for a general policy. There are some other things that are necessary before a possible merge, that I didn't do, either because I couldn't or because I wasn't sure you would play along.

First of all, this policy does not break most anything. Can be further restrticted, but then it will break stuff on desktop environment that are not gnome. So for now, in progress, getting there, more capabilities will be stripped away, for sure.

Now, your make process has an option --full. For the seamless integration of a full policy, this need to a go go and the full policy has to be included in any case. No option to choose, since this is a rather lack policy that protects what is important and protects the integrity of the policy itself. For that, you would have to play along and do the stuff in go so that the _full folder can be abolished.

All the fallbacks to unconfined space also have to go. This is not the utmost priority, but I will most definetely create pull requests eliminating those escapes to unconfined space one by one, if you accept this full policy in. You don't have to worry about this yourself. Just check my pulls to see if they are a ok.

Also at some point I would want to strip mac capabilities alltogether from all binaries in all paths. Then we would have an immutable mac policy, in a real sense. But this is of course, a little overkill to be the default. But I am willing to implement a special installation mode in the makefile that would make sure of this. I plan to call this option automaticaly when the operating system is Whonix or Kicksecure. With time I will create the pulls, don't know if you would accept.

So what say you good sir. These sound reasonable to you? Kicksecure's full system policy is better developed directly here. But if you prefer, Kicksecure can also do on its own, tho it would be infinetely more difficult.

[nobody43]

Looks interesting. But could it be done without w^x violation?

[monsieuremre]

Looks interesting. But could it be done without w^x violation?

Actually, with the amount of profiles here, I think yes. This profile was designed to work with around 150 'selected' profiles from this repo.

[roddhjav]

Nitpick: add a new line after the abi definition.

[monsieuremre]

Sure.

[roddhjav]

Use @{MOUNTDIR} instead of /media/ and /mnt/

[monsieuremre]

Sure thing.

[roddhjav]

Not ideal. But acceptable as all important programs already have a profile and will therefore transition.

[monsieuremre]

Will be more acceptable. Having all the profiles, I can actually strip a lot more capabilities.

[roddhjav]

Note sure about this. systemd really does not need disks access?

[monsieuremre]

My understanding is, only select services do, which have their respective profiles. Because this caused no breakage or slowdown.

[roddhjav]

I think you should test it again. With earlypolicy, it prevents udevd to start, and the boot cannot finish.

[monsieuremre]

Ooof. I see. Will fix.

[monsieuremre]

I don't understand why systemd-udevd tries to run under full-policy eventhough we have a dedicated profile for it. I think this migght be the cause of the issue. Is this a bug, or is it about how we load the profile? The installer seems to skip this profile for some reason.

[roddhjav]

Without earlypolicy, this is because the old initframfs hook only load the profile for systemd. So at very early stage (when udevd is started) there is no profile for udevd yet. earlypolicy fix it as all profiles are available from the cache from the very moment systemd starts.

Then, it moves to the second issue. It is a due to a no_new_privs error. If you look at the apparmor log with aa-log -s | grep error you should see that it cannot transition to some profile due to no_new_privs, and therefore the transition fails and the program runs inside the parent profile. As the parent profile currently denies disk access, the boot is broken.

[roddhjav]

Thanks, full system policy is part of the goal of this project, so this as definitely a place here. It has not been implemented because of time constrain, and due to some technical issue in apparmor.

To sum up my view of your PR:

1. I am going to merge it (after you include my comments). A not perfect solution is better than no solution at all.
2. The current structure is good for now, they will be some major improvement to be made latter. (For the why: apparmor 4 will bring some new feature that will make this easier. For example they will be a new unconfined profile, to restrict program without profiles). It will also have to be made compatible with other distribution than the dpkg based one (currently you need an initframfs hook to load, there is a better solution - currently testing it)

High level comments:

First of all, this policy does not break most anything.

Did you tested it on other system than Whonix? How much did you tested it on whonix?

Now, your make process has an option --full. For the seamless integration of a full policy, this need to a go go and the full policy has to be included in any case. No option to choose,

This is a no go: doing this will most likely break everyone system.

Writing normal profile is already a very complex tasks as one have to carefully check all normal feature of a software, then to tests the profile over a long period of time on multiple distribution. Even with this I very often get report with issues in profiles.

Now a full system policy is a VERY special profile that goes way beyond normal profile. So we will need a considerable amount of tests, redesign, and fixes before to have it as default solution.

It is good to also mention that for such a profile, the security model of the target distribution may change some design (for example I remember that for Whonix UDP can be blocked as TOR does not support it).

What I can do however, is to add a new full-policy option, and Whonix can simply use this option to build. In time (as in 2 years), with testSSSS, the option will become the default.

All the fallbacks to unconfined space also have to go.

That simple to do, the builder system can handle this.

Also at some point I would want to strip mac capabilities alltogether from all binaries in all paths.

This is not possible, they are some programs that generate and reload mac on resource creation: all sandbox manager. For example: libvirtd, docker, snap. They generate new profile on VM/container creation tailored to the VM/container.

Also, the profiles are currently compiled on the host at install/update time for the specific kernel version that is installed, so this would be an issue too (but we can think of workaround).

Let's go deeper:

• Setting the attachment to @{lib}/systemd/** is an issue: it should be @{lib}/systemd/system as otherwise all systemd tools would be confined using this profile instead of their own.

• One of the issue with such a profile is

owner @{lib}/** rwmlkPix,

It goes the same for /bin/, /var/ and /boot/. It is acceptable as all important programs already have a profile and will therefore transition (transitions that will lead to "no new privs" issue for some programs). However, this also decrease the usefulness of the profile. I am OK with it right now, but it will have to be improved.

• I really don't think that /boot is needed.

• Remove all deny .... Once the profile is enforced they would be denied anyway. This will only break your dev system (and cleanup some logs). Pro tip: do not use deny too much when writing profiles.

• Can you add the following lines at the end:

  include if exists <usr/full-policy.d>
  include if exists <local/full-policy>

This is really a must for full policy profile that may be extended by application and admin.

• Move the profile into groups/_full/full-policy

[monsieuremre]

For example they will be a new unconfined profile, to restrict program without profiles).

A yessir but far as I understand it is being added mostly for the new unprivileged userspaces feature. And it is still wastly limited because unconfined profiles are also bound to a path just like normal profiles. So this doesn't make away the need of a full-system policy.

It goes the same for /bin/, /var/ and /boot/. It is acceptable as all important programs already have a profile and will therefore transition (transitions that will lead to "no new privs" issue for some programs). However, this also decrease the usefulness of the profile. I am OK with it right now, but it will have to be improved.

The inherit options is there only as a fallback option. So long there is a seperate profile this should not happen anyway. And even it is inherited, the default policy is in many senses more restrictive that the the program cannot achieve anything malicious anyway. I am pretty sure I can get rid of the attach_disconnected flag, which is more problematic that others probably.

Remove all deny .... Once the profile is enforced they would be denied anyway. This will only break your dev system (and cleanup some logs). Pro tip: do not use deny too much when writing profiles.

Yes, as point out in the comments. This was done for clearance for the reader. I will hande this in comments and get rid of the deny lines. This is would be better as you said.

Can you add the following lines at the end:

include if exists <usr/full-policy.d>
include if exists <local/full-policy>

Of course. Conventions are important.

I really don't think that /boot is needed.

If anything and everything grub has its own profile, then yes you may be right. But this way I want a way for the root user to edit the files there with its privileges. This profile is meant to confine everything. No utilities, not nano, not vim, not bash, not anything has any escape.

This is not possible, they are some programs that generate and reload mac on resource creation: all sandbox manager.

You are absolutely right. That's why I suggested to add this as an opt-in option. Ideally, this would be the default when building a .deb that is targeted for whonix/kicksecure. Even in that case some select profiles with capabilities would exist, but they would be configured in a way that they work only automated and are inaccessible for the end user. You don't have to incorporate this to toher defaults. But let me add this as an option in the makefile, and let me create a kicksecure target with said option activated as default. Untrusted root is something whonix tries to implement. And this is the only clean way to achieve this.

All the fallbacks to unconfined space also have to go.

That simple to do, the builder system can handle this.

Right. This is actually not that hard. Just running a bunch of sed commands right? To be honest, yes. To be even more honest, no. Yes for the rUx and Ux and all the classic stuff it is the solution. But there are also a lot of rPUx stuff you have in some profiles. These seem intentional. I don't want to break anything, but these would have to be replaced with rPx -> full-policy,.

As pointed out, I can also get rid of the m when calling binaries as much as possible too. Which should work.

Did you tested it on other system than Whonix? How much did you tested it on whonix?

I did not test this in whonix. I tested it in a stock debian, with gnome, with KDE, with xfce, with xorg and with wayland, and all of the same also in a kicksecure distromorphed debian. I did basic browsing with firefox, downloaded repositories, compiled binaries, and ran them in the downloads directory, to see that they work well, which they did. I tested the unconfined processes with the --paranoid option to make sure there are no unconfined profiles, which there wasn't. During these tests, everything was enforcing, and nothing was in complain mode. There were only around 200 select profiles that I deemed critical tho, not everything. Thats why the policy can now be stricted further, with all the other profiles being there.

Move the profile into groups/_full/full-policy

Was my initial intention. But your make process looks for two seperate files, init and systemd, with those specific names. I will do as you say, but you have to fix that. In the future, as tests results a ok, we can split the profile way you want. But for now we have one profile. Please adjust the the thing so that it looks for groups/_full/full-policy only when invoked with --full. I don't know go, so I can't help you.

This is a no go: doing this will most likely break everyone system.

I see where you are coming from. Would you consider this with the complain flag and no deny lines? It will be like unconfined space for practicality. But, the project will be ready for the future, it will be just switching the mode from complaining to enforcing. Eliminating all possibility to go into unconfined space is the main goal. Because as I said in my repo, given enough privileges, it is really not a genius' game to circumvent AppArmor policies. Paths are the only thing it uses for 'authentication'. That's why many people rightfully point out SELinux is more solid. But with a full-policy, we make AppArmor not only as good as SELinux, but better in a sense, because it is maintainable by human beings.

[roddhjav]

Tests

So I did a lot of tests on your profile, and they are a few issues. However, they are quite common for this kind of profile.

1. As expected, all systemd tools are confined under the full-policy profile not under their own. This is a dealbreaker as all systemd-* profiles are far more restrictive than the global full-policy, if we keep it this way, it would decrease the security of the profiles set.
2. Even when fixing the attachment the issue, a lot of programs stay confined under the full-policy profile due to "no new privs" problem.
3. To fix this problem we need to extend full-policy with enough rules. We also need to very carefully test the transition to the systemd-* profiles and ensure they all work as expected.
4. It will result in a profile that gives way more permission that what it could ideally give. Decreasing the usefulness of such a profile (hence my initial comments on the limitation of full system policy right now). As this is still an improvement over the current status we are still moving forward and fully support it.

Additionally, the profile is missing some rule like (I can add them later don't worry about them):

  /etc/init.d/* rPx,
  /usr/share/unattended-upgrades/unattended-upgrade-shutdown rPx,
  @{lib}/snapd/snapd-apparmor rPx, # I will add the profile later

Design

I have added Whonix support in the build system & in Gilab CI. Also, we are going to merge your full-policy profile with my all-time work in progress full system policy (btw, thanks to your PR I am finally working on this). You will have to update your profile to the new state of the art for full system policy (no initframfs hook needed anymore). To do this:

1. Rename the profile systemd and add your content inside the existing groups/_full/systemd file:
   • Keep the header comments (add your copyright line obviously)
   • do no put any profile attachement, the profile is directly loaded by systemd on startup.
2. As already documented in https://apparmor.pujol.io/development/structure/#full-system-policy, add the following into /etc/apparmor/parser.conf:

write-cache
cache-loc /etc/apparmor/earlypolicy/

3. Build as in apparmor.pujol.io/enforce/, but with make full instead of make enforce (a make full-enforce will be added later).

Furthermore, even if we call it full system policy, this is mostly a profile for systemd (PID 1). Not for a random user or system program. Therefore, it has to include everything that systemd needs (in other words: a lot). This is also why the future unconfined profile will change a lot of things.

My initial idea was to split this in multiple profiles:

1. Keep the systemd profile for systemd only (not used for fallback at all)
2. Have a systemd-user for system --user (still a wip)
3. Have a default (and a default-user) profile configured as fallback profile (thank to rPx -> default and to pam)

As much as I like this structure, it will have to wait for apparmor 4 to be implemented realistically.

Other

All the fallbacks to unconfined space also have to go.

That simple to do, the builder system can handle this.

[...] But there are also a lot of rPUx stuff you have in some profiles. These seem intentional. I don't want to break anything, but these would have to be replaced with rPx -> full-policy,.

This will have to be tested, but as you say some rUx are here on purpose and will break everything unless the fallback profile is really large.

the default policy is in many senses more restrictive that the the program cannot achieve anything malicious anyway.

The default policy is more restrictive? More restrictive compared to what? If you compare next to an unconfined program, yes obviously. Now, thanks to this project, you should not see a lot of this program (cf the concept page)

My main concern is that the default policy may still be too large because let's be honest, the systemd profile is similar to a full root access profile.

I am pretty sure I can get rid of the attach_disconnected flag,

This is highly unlikely, this flag is needed for all programs running (and starting) sandbox, and systemd starts a lot of services inside sandbox...

As pointed out, I can also get rid of the m when calling binaries as much as possible too. Which should work.

Most of the time, this would not work as it is here for a reason... (but they might be some exception)

This is a no go: doing this will most likely break everyone system.

I see where you are coming from. Would you consider this with the complain flag and no deny lines? I

Nope... as you can see, having a profile ready to go on all distributions is not an easy task. I won't make it the default until it is fully tested. However, help is more than welcome on the test part of the project.

[monsieuremre]

As expected, all systemd tools are confined under the full-policy profile not under their own. This is a dealbreaker as all systemd-* profiles are far more restrictive than the global full-policy, if we keep it this way, it would decrease the security of the profiles set.

Roger. Will fix and replace systemd/** with systemd/systemd. My reason to choose this was this wiki page. I tried following the instructions.

To fix this problem we need to extend full-policy with enough rules. We also need to very carefully test the transition to the systemd-* profiles and ensure they all work as expected.

By this do you mean carefully limit the transition rules?

It will result in a profile that gives way more permission that what it could ideally give. Decreasing the usefulness of such a profile (hence my initial comments on the limitation of full system policy right now). As this is still an improvement over the current status we are still moving forward and fully support it.

Good to hear. I am positive I can wastly lock down the profile further. Will do today. But my question is, in what sense do you think the profile is too permissive? I will focus on that more. Is it the capabilities or the allowed paths? I am planning to pretty much lock down most capabilities that can be used by non-root users to escalate privileges. But I think you are more bothered with my slack file permissions than the capabilities. Is this the case?

And also, how is the nonewprivs a problem? I do not unterstand this.

I have added Whonix support in the build system & in Gilab CI. Also, we are going to merge your full-policy profile with my all-time work in progress full system policy (btw, thanks to your PR I am finally working on this). You will have to update your profile to the new state of the art for full system policy (no initframfs hook needed anymore). To do this:

This is awesome. Will do.

This will have to be tested, but as you say some rUx are here on purpose and will break everything unless the fallback profile is really large.

Well, it is large enough to accomodate most functionality but still limiting in a sense that it is a huge improvement.

My main concern is that the default policy may still be too large because let's be honest, the systemd profile is similar to a full root access profile.

Only if you design it that way. My initial goal is to create a severely limited root. But just not yet and not as the default, as you pointed out the issues. I don't want to cripple root but I don't a root process to have means of circumventing the policy.

Additionally, the profile is missing some rule like (I can add them later don't worry about them):

Thanks for pointing out. Will try adding them.

My initial idea was to split this in multiple profiles:

I would love this. But I couldn't even manage to make two profiles work, and I don't even know how to approach implementing this, due to lack of resources or my unability find them.

[monsieuremre]

I addressed all the little and medium things you mentioned. They are now fixed. Profiles is also vastly restricted further. And I am planning to further restrict it in terms of mount capabilities. I also will try removing the m from binaries as much as possible. Please do tell what else needs improvement/fixing. I will also replace sytemd/** but this will need testing before i push, but will do today most probably.

Also would it be possible to add new tunables in your project? Stuff like @{etc} for /{,usr/local/}etc/ or @{tmp} for /{,var/}tmp/. These would improve readability.

[monsieuremre]

Removing sys_chroot might have some adverse side effects. I hoped everything would be covered within the profiles we already have here.

[monsieuremre]

The installer still explicitly looks for init and systemd profiles and does not care for the full policy, when the option --full is given. Changing the name causes other issues because the installer still looks for init too, which breaks everything. This needs to be addressed within the installer.

[roddhjav]

The installer still explicitly looks for init and systemd profiles and does not care for the full policy, when the option --full is given.

You probably need to update your branch from master, I updated this recently. Also, filename and profile name must be systemd.

Profiles is also wastly restricted further.

We need to test it, it might generate other issue (I will come back on this later, I need to do some tests on my side). But right now there are a lot of issue regarding no-new-privs (see No New Privileges Flag)

[roddhjav]

Will fix and replace systemd/** with systemd/systemd. My reason to choose this was this wiki page. I tried following the instructions.

This doc is deprecated (4 years old), newest method is: https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorInSystemd#early-policy-and-boot. Btw, as systemd directly loads the systemd profile, you should not put any attachment at all.

[monsieuremre]

But right now there are a lot of issue regarding no-new-privs

What are some of these specifically and how would I go about fixing them? I can't observe any practical problems out of the box. Also, this does not seem to be going anywhere even in apparmor version 4, so we would need to find a better way here if necessary.

[roddhjav]

Yes, nnp has been a pain for a long time for all LSM (so selinux too) - and it is the main reason why full system policy has not been implemented earlier in this project.

To sum it up:

• No New Privileges is a flag preventing a newly-started program to get more privileges that its parent. So it is a good thing for security. And it is commonly used in systemd unit files (when possible).
• This flag also prevents transition to other profile (because it could be less restrictive than the parent profile), (so no Px allowed).

The possible solutions (we might use all of them depending of the program):

• Ensure the programs do not run with nnp flag by disabling NoNewPrivileges in the systemd unit (or another option implying it)
• Inherit the current confinement (ix)
• Stacking

See https://apparmor.narkive.com/lTYA7lIk/question-about-no-new-privs & https://apparmor.narkive.com/gz6XOZ39/avc-allowed-operation-exec-info-no-new-privs-error-1

[monsieuremre]

Manually disabling NoNewPrivileges under /usr/lib/systemd for units that are known to use this seems to be the go-to option. This would be possibly be done when the full system policy is enabled. Is there anything that would stop us from doing this?

[roddhjav]

• From a security point of view it is not ideal - although we would confine the profile, so it might not be a big deal
• It will be a pain to configure (we might have to edit this flag for a lot of program)

I am going to do some tests and see what is the best option depending of the program. I think stacking could be a better solution for some program.

[roddhjav]

I got it working fine. They will have some improvement to do later, but it is a start. Can you rename the profile, so I can merge it and add update it.

[monsieuremre]

I got it working fine. They will have some improvement to do later, but it is a start. Can you rename the profile, so I can merge it and add update it.

Good to hear. Will do. There are obviously a lot of improvements to be made. Not just further restricting the profile, but it seems to break some little stuff here and there. These are mostly related to file permissions in /etc in my observation. Anyway, it is on the way.

[monsieuremre]

I did the name change but the path in profile remains @{lib}/systemd/**. This due to a lack of testing on my end. I didn't want to just change it to @{lib}/systemd/systemd with no testing and risk breakage.

[monsieuremre]

I also want to address some questions I have in my mind. I couldn't find answers to these no where.

First: None of your profiles have capability audit_read. Can I also phase it out here? I feel like it just 'might' break reading the audit files manually even using something like cat? Would that be the case? When I test it, it doesn't seem to have any affect, except for some random files in does, but for some reason not always. I might be testing wrongly. Independent of my experience, would this be a problem you think?

The same applies to capability audit_write. Like a lot of packages that need that already have it on their profiles. Would deleting this break stuff potentially?

And also

# network unix, # same as just allowing unix?
# network local, # a thing?

Can you comment on this part. I get all the names options from the man pages. And it seems network unix is just the same as unix but not quite? Like what is the difference. And also network local should be a thing technically reading the man pages, but it seems it isn't for some reason. Can you comment on these please?

[roddhjav]

First: None of your profiles have capability audit_read

Per the manual, audit_read allows reading the audit log via a multicast netlink socket. This means, the cap allow reading the kernel logs, not software log (in some /var/log/**)

Therefore, systemd-journald has this caps, and systemd needs it too.

It goes the same for audit_write systemd needs it. You need to stop considering this profile has a global default profile but as the profile for systemd as PID 1. Such a program needs some special access. Therefore, the systemd profile is a really bad candidate to also play as default fallback profile.

network unix, # same as just allowing unix?
network local, # a thing?

network unix, & unix, are the same, however, they allow to access different control (network settings and unix settings). So both can be used.

[roddhjav]

Merged!

I have integrated my latest tests, and kind of rewritten everything as the architecture changed quite a lot. Please have a look at the new doc page. I have started #252 to follow up on this matter as this is clearly only a wip.

Also, for future test, I encourage you to use one of the test VM provided: https://apparmor.pujol.io/development/integration/#test-virtual-machines