I don’t know. I found requirement for /etc/ld.so.preload pretty unexpected.
Also issue as per post AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy - #76 by HulaHoop was unexpected and thereby messing up the KVM release.
Causing quite more issues than expected.
Please send patches. Or perhaps let’s reconsider and move to apparmor-profile-everything?
I thought that was for the testers only version?
If so, it’s not that bad.
What do you mean?
It’s actually stable, ready for release. Except this issue which strangely only happens in KVM as far as I know.
Move pam tally2 info and permission lockdown apparmor profiles from security-misc to apparmor-profile-everything.
That won’t work. We’d need to use ix rules for those in the base abstraction which would break for anyone not having apparmor-profile-everything installed as there’s no other profile it can use.
Is it possible for an attacker to install a root SSL certificate to decrypt TLS traffic, mitm apt and inject a malicious kernel during upgrades?
GPG verification should prevent this but this has been bypassed before so I don’t want to rely on it completely.
Another way to prevent this would be to use onion mirrors unless Tor traffic can be mitmed if the user’s system is compromised (I don’t know if it can or not).
I guess so. You could test this by moving the folder that contains SSL certificates. /etc/something, part of packages ca-certificates or so. So that folder needs to be protected from root too.
That was the default in past but undone due to unreliability.
Set to run unconfined if profile does not exist?
Contact upstream if this cannot be resolved?
Ideally with a simplified question.
Also good to point other potentially interested people at the existence of this package.
The folder is /etc/ssl/certs/. Moving it makes apt fail.
Protecting that folder would prevent non-malicious changes (e.g. updating certificates) although we can probably restrict it to apt only.
We can but I really don’t like the idea of it potentially running unconfined.
That would be a good idea.
Also, an attacker can just install a local .deb file containing a malicious kernel with sudo apt-get install /path/to/malicious-kernel.deb which allows them to do whatever they want with the kernel images.
Is it possible to prevent this and only allow installing from repositories?
A bit hacky but maybe we can do
deny /**.deb rwmxkl,
/var/cache/apt/** rwmpixkl,
So apt won’t be able to access any .deb files on the system except ones in /var/cache/apt/. Unless the filename doesn’t have to end in .deb (dunno what apt would do then).
This might also be able to be prevented with a wrapper.
apt doesn’t matter much. dpkg is actually writing to these files.
(but apt uses dpkg)
Ok.
How would that be possible? Once apparmor-profile-everything is installed, the profiles would be in place and used.
Yes but the profile is for /usr/bin/apt-get and dpkg is executing under the same profile as it’s used by apt-get.
It probably isn’t possible but it’s best to be sure and not touch any unconfined rules IMO.
Both apt and dpkg support a TON of command line options. Proably one to change the path to the SSL CA certificates. For example I am not certain that path to sources.list or sources.list.d can be changed. (Whonix build script uses that.) Also some environment variables.
For the purpose of apparmor-profile-everything it is probably best to prohibit direct access by root to apt / dpkg. All access should be through (a) wrapper(s). (Probably an apt wrapper that is allowed to call dpkg.)
The wrapper would have a (configurable) whitelisted amount of allowed command line options (and perhaps environment variables if there is an important/sane use case.) A blacklist approach is probably not possible since these command line parameters are too complex.
The wrapper could be created any time. Integration (with uwt) we can worry about once the wrapper exists.
Configurable by who? The user? If so, nothing stops an attacker from abusing it.
Very little options would be needed for ordinary usage so a configurable whitelist probably isn’t necessary.
It would be very important and sane. Otherwise an attacker could use some LD_PRELOAD tricks.
We can unset all environment variables with
for env_var in $(env | sed -e 's/=.*//g'); do unset "${env_var}"; done
Important ones like $PATH can be excluded.
We could alternatively use apparmor’s environment scrubbing which unsets dangerous environment variables but I think the method above is far more effective.
I’m not sure if this should be opt-in anymore. Breakages will be easy to fix for the most part and issues shouldn’t really occur unless doing some crazy stuff. The security advantages of this are great and it plugs many holes already.
By those booting in a different boot mode. Or temporarily disabling apparmor-profile-everything. Or when booting from a (offline) live iso rather than hdd.
Too complicated. Easier options. Environment variable sanitization is a common thing.
Can be considered after testing (call for testers blog post) when ready. Let me know when time comes / draft.
Also needs to not restrict user freedoms. Grub boot menu entries to boot into “full access admin mode”?
I don’t think we should use a grub boot menu for that. Users might see “admin mode”, think it would fix their problem, boots with it, it doesn’t fix their problem and now everything runs unconfined.
Any other option to not prevent those users who choose to use third party repositories to allow them easily do that?
Bothered me that my old phone had locked bootloader and refused root access no matter what. Not intending to do that same.
Also any other advanced configurations (inclusing those I can’t even imagine) shouldn’t be prevented just by refusing full root for better security.