Full system policy profile - Question

[monsieuremre]

The full system policy seems to be not allowing anything ever unless a profile is present. I know the development of this projecty aims not to allow everything (or a large area) and blacklist some sub areas. Does this also apply to the full system profile? So, is this intentional?

With the profiles you have available for daemons and services with high privileges, Kicksecure's apparmor-profile-everything can be wastly further restricted and be used as a full policy that wouldn't require a profile for everything to run. Licenses are compatible. Is this of interest, or is it out of the scope of this project?

[roddhjav]

There is no full system policy (yet). The systemd profile is for systemd --user, the init profile is empty, it is here only to not break the build system, as this is pretty much a WIP.

However, yes, the very experimental systemd profiles only allow well know profile because:

1. By design of this project, if systemd starts a privileged/user service, it must be confined (and a profile must exist).
2. You can see the current set of profiles as a prerequisite to ensure we have profile for all services.
3. We can do this as distributions and other programs can add rules in the usr/systemd.d directory
4. It is not finished

Full support for Whonix is planned. Actually, there is already some structure to support Whonix, see for example: https://github.com/roddhjav/apparmor.d/blob/38648bcba1798ef9aeec13ee7fb93a1fe561ecd0/pkg/prebuild/tools.go#L17C2-L17C16. However, again, this is a WIP.

The reason why all of this is still a WIP (and why it will stay like this for a while) is because of no new privileges restriction as apparmor prevents transition to profile with more privileges. They have been some work to allow a given profile with more privileges however, this is not supported by apparmor yet.

Systemd is mostly starting other program with more privileges hence this limitation that is raised quickly. See:

apparmor.d/apparmor.d/groups/_full/systemd

Lines 54 to 57 in 38648bc

	@{bin}/pipewire rux, # FIXME: no new privs
	@{bin}/pipewire-pulse rux, # FIXME: no new privs
	@{bin}/pulseaudio rux, # FIXME: no new privs
	@{bin}/wireplumber rux, # FIXME: no new privs

If you restrict Kicksecure's apparmor-profile-everything you will at some point reach this limitation. However, it should be possible to restrict it quite a bit by leveraging current profile. But again, I have some time constrain.

[monsieuremre]

I would be willing to work on something like this. But first thing this package is not the easiest to debug. There is the known issue that startup in gnome takes forever with this package. This is also true even if everything is in complain. I have tested for the purpose of maybe implementing a full system policy down the line, only the profiles in the group systemd. They were all in enforcing mode and there was no delay. Added upon them all the profiles in group apt, and the boot is still ok. And by the way, these are all in enforcing modes. So the most critical profiles for me are all perfect.

Some profile somewhere slows downs the startup even when in complain mode. First this should be found. But my other suspicion is that, in fact, no profile is responsible for this delay, but rather the fact that we are loading up 1500 profiles every time. I wanted to test this by disabling some of the profiles but this is also not a piece of cake because of the hook. There needs to be an easier way to disable the hook on startup to reload every profile even if I disable them manually.

Because I want to say: I would be interesting in only a number of the profiles here. All systemd, all root processes and internet facing daemons and all suid binaries. Literally by having only these profiles, a quasi strict everything profile can be written for init.

[roddhjav]

You can already select what profiles you want to include in the package by editing dists/ignore/main.ignore. For example adding apparmor.d/groups/gnome will ignore all gnome related profiles.

Beware, by if you ignore too many profiles, you may also ignore profiles that are dependencies of others.

no profile is responsible for this delay, but rather the fact that we are loading up 1500 profiles every time.

It is not an issue about the number of profiles: there is no delay on a server or on KDE. It may (or may not) be related to dbus.

[monsieuremre]

Beware, by if you ignore too many profiles, you may also ignore profiles that are dependencies of others.

I found a solutions to this problem and created an issue. I can directly create a pull too.

[monsieuremre]

I would really appreciate your help, if you could explain some little things. I am going to fork this repository to make a full system policy. I won't be able to merge this to your project because it is certainly against your first rule. The full system policy is going to be really slack, in most senses. I will enforce this policy with everything. If the user installs a custom binary or compiles one in some random path, that should work out of the box. My only concern is that this full system policy will prevent changing the mac policy or apparmor profiles. It will also manually deny some sensitive stuff that might be used to circumvent the policy on other binaries. It will also not have most of the capabilities, to prevent privilege escalation.

Any guide on full system policy explains creating only one profile. For the path ${lib}/systemd/**. When I create a profile for this path, I can enforce a full system policy, with all your custom profiles. But I do not understand how you plan to implement this with two profiles under _full. One of them does not even have a path or profile name. What does splitting the profile init-systemd into two distinct profiles bring? What paths are they meant to use? Official wiki only considers one profile init-systemd.

[roddhjav]

Nice work with your project.

In the coming weeks, I will try to test full system policy deeper, at minimum in order to ensure good integration with an init profile not too strict.

I am well aware that it is currently not possible to make an init profile really strict. Therefore, fell free to merge your init profile into this project.

[monsieuremre]

I can gladly do it. But that would't suffice for a full system policy. I have also adapted the profiles I ported from your project to work with a full system policy. These changes would have to be made here too.

There has to be no way possible to have a valid way of going into unconfined space. Anything that has /something/binary Pux, or anything pux cux Pux Cux ux, that is anything with a u, needs to go. They have gotta be replaced. From /old/rule Pux to /new/rule Px -> full-policy. At that point, the full policy should not be opt-in. It has to be opt-out if wanted. Because it is the only thing that can ensure the policy itself is protected even from the root. Even if this were a rather slack profile, it means a lot. I got to this level of confinement with just profiles for systemd and some other important stuff pretty much. So this slack profile can be restricted infinetely more with all the 1500 profiles, needless to say.

So even after merging there would be little stuff like these to adjust. And also I would have to ask: you have seperate profiles for systemd and init for some reason. As I already mentioned, I could not find any resources on how that would work. All the official documentation guided me to creating a single init-systemd profile. How would this work? Would I have to split the profile for the full system policy into two or like is one of them the 'real' full system policy.

[roddhjav]

you have seperate profiles for systemd and init for some reason.

My initial test is to have a profile for systemd as user. This profile would be launch as Px from the init profile. While the init profile is launched as usual during the boot process (actually, even this part should evolve).

Splitting the profile in two would improve security by a lot as user and system version of systemd are quite different.

See: https://apparmor.pujol.io/full-system-policy

The rest is mostly technical requirement to make it work with the current version of apparmor (eg Pux to Px -> full-policy...)