
Let's enable AppArmor by default (why not?) - boramalper
https://lists.debian.org/debian-devel/2017/08/msg00090.html
======
esaym
If people rant and rave about how hard pulse audio is to configure, then I can
only imagine how much kick back there will be about having to configuring
apparmor etc. Just saying.

Personally, I'll be keeping it disabled. I used to use selinux, but eventually
stopped as I didn't find the constant headache of trying to figure out why
something wasn't working was related to SE or not worth it.

~~~
SteveNuts
Disabling SELinux is a mistake, especially now that there are tools that will
scan the audit.log and tell you exact commands on how to fix each thing it
finds.

If you want to do something weird like allowing nginx or apache to serve your
home directories, it takes maybe 5 minutes to google the correct se context to
set on the directory and apply it, otherwise any standard installation works
out of the box.

There's literally no reason to turn it off nowadays, other than
laziness/unwillingness to learn.

~~~
jron
I can think of a great reason to disable SELinux; you actually use linux for a
workstation and don't want fight with it every time you install a new
application.

~~~
Hello71
do you also do chmod -R 777 /?

~~~
yjftsjthsd-h
Pretty sure that actually breaks stuff

~~~
jameskegel
This is correct.

------
ausjke
Good idea for the server at least. For my development machine I need be able
to disable apparmor easily(when it breaks my desktop). Increasing security
sometimes decreases usability, especially when I just need Debian/Ubuntu for
development and browsing.

~~~
IgorPartola
Isn’t compromising your development machine way worse than a random server?

~~~
XR0CSWV3h3kZWg
My dev machine can't access prod data. My dev machine doesn't deploy to prod,
the attack vector would be inserting malicious code, which would need to pass
CR before being compiled on a build server and then deployed to prod.

In my case impact to the business would likely be less if my dev machine was
compromised than if prod was. It'd depend on the dedication and skills of the
attacker though.

~~~
theossuary
I'm really curious if it's actually true your development machine can't pivot
into prod. You don't have sufficient access on the build/ci/deploy servers to
pivot into prod without code review? You don't have passwords saved/stored
that are reused in critical/prod infrastructure? You have _no_ way of
accessing prod?

That seems crazy to me, as I'm able to SSH into prod with a single command and
password. I guess I'm further on the ops side, but still.

~~~
derefr
Depends on what you mean by "development machine." My Macbook has those
credentials on it, but the Ubuntu VM running on it, which I do most of my
development within, does not.

Personally, I wish more operating systems came with an installer checkbox for
"this will be used as a VM within an environment that already has its own
security mechanisms; stop doing anything related to security/multitenancy
(i.e. automatic login, no sudo password, no screen lock, etc.) and just let
the host handle all that." Every time I set up a development VM I have to go
to a bit of trouble to create an environment almost-but-not-quite like that,
thwarting all the carefully-designed-in, yet redundant, security.

Makes me miss MS-DOS and Windows 3.1/95 a bit; those were truly "Personal
Computer operating systems", in the sense that they assumed that there was a
1:1 correspondence between physical access to the hardware and the privilege
to read/write/execute arbitrary data on said hardware. It'd be neat to have a
version of Linux (or Windows 10) with that sort of "retro" security model (but
still with process sandboxing; just because any _user_ has rights, doesn't
mean any _program_ should, because programs aren't always the authorized
agents of a user's will.)

~~~
stephenr
Wait, youre using a vm for dev, using the vm GUI/desktop environment?

Either way, it sounds like Vagrant may help. Most baseboxes target headless
server dev and don't have a DE but a few do, and of course you can build your
own base box and then customise via a provisioner for each different project.

------
zzzcpan
"it can prevent exploited server software from accessing data it does not own
and executing arbitrary code"

Isn't AppArmor overly broad for something like that to be true? Exploited
server software would happily provide access to the data of all users, since
usually they all are withing the same trust boundaries anyway.

I think it's not a good idea to enable "security features" simply because it
feels like they help, without even a threat model.

~~~
pwman
That's not how AppArmor works provided you lock down your server software
properly -- say the server running is NTP -- that NTP server is only able to
read /etc/ntp/* and /usr/sbin/ntpd only able to write /var/log/ntp* only able
to execute /usr/sbin/ntpd Now you've radically limited what an exploit of this
particular server can mean.

~~~
zzzcpan
Not a good example, chmod, chown and chroot accomplish pretty much the same
thing.

~~~
boramalper
How? AFAIK, the only way to do it is to create a different user for each app,
like Android, which seems absurd to me.

------
qznc
As an Ubuntu user, I suffered from AppArmor a few times and removed it.
However, these days it seems to work. Worth a try, Debian.

------
baldfat
It looked like AppArmor was done for. Thanks to OpenSUSE for saving it!

------
mtgx
If wonder if the way most Linux "apps" work right now is what's keeping Linux
from adopting more advanced security measures by default, such as Grsec,
AppArmor, SELinux, or even ASLR...

Instead of having one self-contained app that either works on it doesn't on
your AppArmor-enabled OS, you have "dependencies".

If a media-player you download doesn't support AppArmor, you can just use one
that does. I think it's harder to avoid dependencies like that, if a library
used by a whole bunch of programs doesn't support AppArmor.

~~~
xj9
i'm pretty excited about flatpak et al, because gnu/linux will finally get
application sandboxing that is reasonably easy to enforce. the dynamic lib
bullshit that the community got hooked has been a huge impediment to
implementing good application-level security on the linux desktop imo

not so much the fact that they are using dynamic libraries, but the foolish
idea that you should keep all of your applications and libraries in a single
namespace in a messy pile. plan 9 showed y'all the way, but you don't listen,
b/c y'all are obstinate.

~~~
hossbeast
Did plan 9 not have dynamic libs, or were they namespaced in some way? Would
love a link to read about this

~~~
pjmlp
Plan 9 had dynamic libraries.

Limbo, the main language for Inferno, only makes use of dynamic loading.

[http://www.vitanuova.com/inferno/docs.html](http://www.vitanuova.com/inferno/docs.html)

------
language
There's some kind of bind here between "putting burden on end-users" and
"putting burden on application developers." Either you (a) ship $LSM with some
defaults that are necessarily general (so as to avoid breaking applications)
and let the user fit filters to their circumstances, or; (b) push for
developers to write/maintain filters baked into their applications (ie. using
some kernel features like `seccomp` and what-have-you).

~~~
ris
seccomp and LSMs do different (and complementary) things.

~~~
language
How so? I understand they're different, but I thought there was some overlap.
Don't LSMs work by hooking syscalls anyway?

~~~
AstralStorm
Seccomp can only disable syscalls. LSMs are more nuanced. Three most important
difference is that it is easy to check if seccomp is available and the policy
is not kept in or on a file.

~~~
language
I was under the impression that seccomp was a bit more flexible (via ptrace()
and BPF fanciness) - although I guess you'd need other co-operating processes
in userspace? I've only played around with it a tiny bit.

Also, both kinds of policy are resident in files. I don't understand your
point there.

~~~
ris
It is flexible to an extent, but you still can't e.g. deference a pointer to a
struct passed as an argument. And that's where much of the interesting detail
is for many calls.

~~~
language
Thanks for the clarification, although I recall messing with eBPF and kprobes
before - pretty sure you can dereference pointers?

editx2: Oh, guess seccomp doesn't use eBPF yet? Suppose that raises a bunch of
questions about permissions necessary for specifying programs that might
dereference kernel pointers and such by emitting `bpf()` calls.

------
pjmlp
Please do, that is already how I use Ubuntu since quite a few LTS releases.

Ideally, every single application would be sandboxed in some way.

------
revelation
The Linux desktop of today still occasionally requires teaching users how to
install new udev rules so they can properly use that USB serial converter or
other gadget sanely.

Now imagine raising that pain to the power of 10, but instead of only weird
USB or "device not found" errors nothing works anymore because "AppArmor" is
blocking syscalls. I can already see the StackOverflow answer that just tells
you to set it to permissive, and you know what, that fixes it everytime, too!

This is just a non-starter. Maybe they should look at deploying ASLR first,
it's not 2000 anymore you know. (Update: they just managed to get this done
with stretch, released 4 months ago! That's only like 7 years late for a
crucial actual security feature)

~~~
AaronFriel
Since the Year of Linux on the Desktop has still not come, perhaps major
distributions would be wise not to use that as a reason not to implement
security features.

Last I checked, the Year of Linux on the Server has been every year for many,
many years. And it's the servers and their vulnerabilities which are exposing
tens of millions users information at a time, not individual Linux desktop
users.

~~~
revelation
Last I checked everyone running Linux on the Server has skipped ahead to
containers so now very little of these syscall filtering games even apply
anymore.

Too late for servers, too early for desktops. That always felt like a succinct
summary of SELinux.

~~~
chrisan
> Last I checked everyone running Linux on the Server has skipped ahead to
> containers so now very little of these syscall filtering games even apply
> anymore.

That's a big jump. Any stats on the so called container usage by "everyone"?
Even here in the HN-bubble everyone isn't running containers

