No. Unless they disable apparmor with the boot parameter and then modify it. Allowing the user to edit it allows the attacker to abuse it.
A locked bootloader and restricted root is an essential part of android’s security model. If you can easily bypass it, so can an attacker.
A user can always just use apparmor=0 as a boot parameter to disable it but I don’t think an ordinary user facing option should be available.
Btw I do think that there are some good things there. Worth replicating in Linux desktop distributions. This is complex, therefore a while ago I wrote my thoughts on that subject here:
Kicksecure - Secure by Default Operating System
Is there a way to say more limited, “don’t use apparmor-profile-everything” rather than saying “don’t use apparmor at all”? Even if a user chooses to boot in “full root mode”, it would be prudent to keep apparmor enabled. Just not apparmor-profile-everything.
The only way to bypass it could be if the user decides to bypass it? No other technical bypass / weakness? “Only” user mistake?
I am not sure. I am leaning towards user freedom, usability rather than locking down security while worsening user freedom. From my perspective, I keep working on Whonix for 7 years already, and now I don’t want to harm/kill the project by creating a situation similar to “Ubuntu amazon search lens” controversy.
This needs to be discussed with the community and cannot be decided on the sideline in a long, very technical discussion.
Created a quick, not so serious poll.
https://twitter.com/Whonix/status/1195951984274075648
But I do know that the wording and bias of a poll influences the result of a poll. Therefore, if you wish to run a differently worded poll, let me know.
This is a huge directional development decision. I’ll be creating a separate discussion and Whonix forum and twitter poll where I explain this change in more laymen terms.
grub allows multi layered boot menus. I.e. after choosing “admin mode”, there could be another screen which explains the risk of this and this likely won’t fix their issue.
There are ways to inform the user. Highlight the importance. And if users still go ahead and shoot their own feet, they should be able to do so.
Although “grub multi layered boot menu warning” could be future work and doesn’t need to be included in the first iteration.
This looks like a great compromise. However if it comes down to security vs freedom, I will pick freedom every time. I don’t feel like fighting with the OS every time I want to do something on my terms. Making different variations of security boot modes that goes the whole nine yards is reasonable as long as I can choose to run without them.
Yes. Modify apparmor-profile-everything/etc/initramfs-tools/scripts/init-bottom/apparmor-profile-everything at master · Kicksecure/apparmor-profile-everything · GitHub to only run if a certain boot parameter is not found in /proc/cmdline.
No. If root wasn’t restricted what stops an attacker from using su the same way the user does?
“security or freedom” is a bit blunt and can make people assume all kinds of things (e.g. NSA surveillance is essentially security over freedom). Would be better if it’s something like “security of the operating system or freedom to customize the operating system”.
That would be a good idea then. I’d be fine with that.
That would be great!
I don’t see any difference between “apparmor=0” and “boot in full root mode”.
Differences are only usability and project philosophy.
As for non-social attacks (attacker instructing user to do that), I don’t see any differences.
I agree. Not easy to word that. Hence, I didn’t even try to seriously word that previously due to time restraints.
That’s an interesting question too. Even though we fortunately don’t need to ask consensus (since finding agreement easier than anticipated)… I’d still be interested to ask. Just interesting and maybe useful for future. Draft tweet.
Which one is more important?
#Security of the operating system or #Freedom to customize the operating system?
Choose one.
^PS
Security of the operating system
Freedom to customize the operating system
(^PS: not sure I should sign with my own name. Anything.)
Let me know if you like any changes to that tweet poll draft.
Awesome! Please implement.
Together with live mode, we’d have 4 boot modes.
“regular” to not call it “restricted”. (We want people use it and hopefully happily don’t notice restrictions.)
But could become convulted if we ever introduce a no-root boot mode? I guess a no-root (root disabled) boot mode (even default one day) would still be useful? no-root (+apparmor-profile-everything) seems most difficult to succeed in a VM escape.
Let me know if you need help with grub boot menu. New menu entries seem easy.
Once figured out (which wasn’t trivial) but now that it’s done grub-live/etc/grub.d at master · Kicksecure/grub-live · GitHub looks easy.
Wouldn’t be hard to add more grub boot menu entries. But multi layered grub menu could be harder.
But a warning screen to warn against full admin mode (with timeout, dismissable, whatnot) could also be implemented blocking (other services from starting) and at early boot using systemd unit file?
It looks great.
I have no experience in custom grub menus so I can’t implement this.
It would be very useful. Root is still far more privileged than the ordinary user even when attempting to create an untrusted root user.
I think a grub menu would be the best approach.
One roadblock. Twitter allows a maximum of 25 characters per poll choice.
Choice 1
Security of the operating system
32/25
Choice 2
Freedom to customize the operating system
41/25
These need to be shortened somehow. Please suggest.
Alright. So for future when apparmor-profile-everything is ready…
And later if no-root gets implemented…
(Didn’t think much yet about the wording. Open for suggestions. Can be done when time has come.)
I am fairly certain, I can add all these boot menu entries. These would run the kernel with different boot parameters. And the kernel or any other program/script else can read these and act accordingly.
But a layered boot menu… A simple yet solid implementation similar to grub-live… Maybe not possible.
Maybe adding (DANGER!) to non-layered grub boot menu makes this clear? But maybe a longer explanation is warranted?
Replace “operating system” with “OS” and “Freedom” with “Able” so it’s “Security of the OS or Able to customize the OS”.
It would be better to give a longer explanation.
Posted. (Could delete and re-post if something wrong.)
https://twitter.com/Whonix/status/1196137962888556544
Alright. Only thing I can think of is during early boot (systemd unit that blocks other services) and waits for yes/no continue boot with timeout (continue boot) (for headless).
I’m not sure the best way to go about this but I created this Debian paste error. It’s a bit of a mess but it works (mostly).
Maybe better a wrapper script that runs env -i another-wrapper to make sure the whole wrapper runs under env -i? Wrapper might be best since then we can whitelist some sane env vars (such as for proper console color settings?)
Or env in the shebang?
#!/usr/bin/env -S -i /bin/bash
Above might even be too much? Even clears SUDO_USER.
We’re not the first ones to do this?
Parsing args better as per BashFAQ/035 - Greg's Wiki
Similarly used many times in Whonix source code and rock solid. (Needs modification.)
## Thanks to:
## http://mywiki.wooledge.org/BashFAQ/035
while :
do
case $1 in
-h | --help | -\?)
return 0
;;
--)
shift
break
;;
-*)
echo "$SCRIPTNAME unknown option: $1" >&2
EXIT_CODE="1"
cleanup "1"
return 0
;;
*)
break
;;
esac
done
## If there are input files (for example) that follow the options, they
## will remain in the "$@" positional parameters.
Also need to whitelist some parameters such as --no-install-recommends, similar ones and whatever comes up later.
Thanks. I didn’t think of using that for this.
How would I parse the package names this way?
Maybe keep the original for loop for “whitelisted_options” and use this approach just for “whitelisted_commands”?
Then nothing will run the other wrapper script under env -i.
Doesn’t work. Create a file with
#!/usr/bin/env -S -i /bin/bash
env
All environment variables are still there.
We can use apparmor’s environment scrubbing on the wrapper and then use env -i /usr/bin/apt-get in the wrapper.
/usr/bin/rapt
#!/bin/bash
env -i /usr/bin/rapt2 "$@"
Apparmor would enforce that users are only allowed to run /usr/bin/rapt and not /usr/bin/rapt2.
Works for me.
/home/user/test:
#!/usr/bin/env -S -i /bin/bash
set -x
true x
env
true y
exit
./test
+ true x
+ env
PWD=/home/user
SHLVL=1
_=/usr/bin/env
+ true y
+ exit
Otherwise there would be a lot more env vars.
Maybe that only as defense in depth and not only solution.
I am not sure I am chasing unimportant details here, but I guess it would be better to run as little as possible with non-sanitized env vars. I.e. the wrapper that checks the parameters is probably best to run wholly with sanitized env.
one
while :
do
case $1 in
update)
two
while :
do
case $2 in
--fix-missing)
break
;;
Do we really need two? Could just be the same loop?
This is because apt supports all syntax.
apt --no-install-recommends install pkg-nameapt install pkg-name --no-install-recommendsapt install --no-install-recommends pkg-nameIdeally, we’d be as non-intrusive as possible. Not breaking existing users workflows / scripts.
Nov 19 15:22:17 host audit[528]: AVC apparmor=“DENIED” operation=“exec” profile=“/usr/lib/security-misc/permission-lockdown” name=“/usr/bin/chmod” pid=528 comm=“permission-lock” requested_mask=“x” denied_mask=“x” fsuid=0 ouid=0
Nov 19 15:22:17 host audit[528]: AVC apparmor=“DENIED” operation=“open” profile=“/usr/lib/security-misc/permission-lockdown” name=“/usr/bin/chmod” pid=528 comm=“permission-lock” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
Nov 19 15:24:59 host enable-firewall[379]: /usr/lib/security-misc/permission-lockdown: line 56: /usr/bin/chmod: Permission denied
packages_list=“$(grep -h ^Package: /var/lib/apt/lists/deb.*_Packages | sed -e ‘s/Package: //g’)”
Maybe a cleaner way? How does APT’s bash auto completion (press tab to complete package name) get the names of packages from?
Maybe we don’t need to whitelist package names and commands? Maybe all commands are ok? Maybe only parameters starting with a dash - need to be whitelisted?
What about removal of essential packages which provide apparmor-profile-everything functionality to begin with? sudo apt purge apparmor-profile-everything Blacklist these?
Removing any dependency that makes apparmor, apparmor-profile-everything work could help an attacker get rid of apparmor-profile-everything
Even swapping the init system from systemd to something else or something else could break apparmor?
Or installing some package that conflicts with the apparmor package would result in its removal, does that exist? Or are there packages that disable apparmor after reboot (another LSM)? Install selinux to get rid of apparmor? Just guessing. No substance yet.
Blacklist approach could have holes.
Seems rather hard to tame APT. Are we the first ones to restrict APT?
Sure, but nothing executes rapt with env -i.
What stops an attacker from using LD_PRELOAD tricks with rapt to prevent rapt2 being run in a clean environment?
How would that work? Especially for the packages.
The dangerous-files abstraction already fixes that. Those files aren’t writable although that abstraction isn’t enabled in the apt profile yet.
The other init would still be confined under apparmor and besides all binaries/libraries are read-only and read-write only for apt.
I see. I would hope that the only thing exposed being env would be more resilient to that then anything else doing by the wrapper.
I’ll see if I can implement the wrapper. Secure, yet not breaking apt’s interface (except for non-whitelisted).
How would dangerous-files block sudo apt purge apparmor?