[pkg-apparmor] A Proposal for Managing and Enforcing Permissions for Applications (GSoC'18)

[Mert Bora Alper]

Hello!

For GSoC 2018, I am planning to propose an *opinionated* security
solution for desktop users to manage "permissions" for
applications/programs on their system, and I am currently looking for
feedback on my idea, and a mentor for my project. The motive behind
the proposal is to create easy-to-use (as opposed to full-featured)
tools to help users protect themselves from the harmful effects of the
(potentially malicious, but sometimes just buggy) applications they
run. Mobile operating systems such as Android and iOS have been using
the concept of "permissions" for a long time, and many users are
familiar with how it works and protects their privacy.

The Software works only with whitelists (and not blacklists); again,
because blacklists (when combined with whitelists) can lead to
unanticipated consequences and confusion. Lastly, it is always better
to state only what is right & acceptable than (trying) to list what is
wrong & unacceptable (as you'll be likely to miss out things). Though
it is also clear that we might need to notify the user that one of the
applications they run is blocked from taking a certain action (so they
can know why the program errs all of a sudden), and yet, we wouldn't
like to flood them with notifications they are not interested in. The
solution is to create "silence-lists": if a blocked operation is
covered by a permission in a silence-list, the user will not be
notified and the operation will still be blocked. This is also, as far
as I know, the approach Android and iOS takes (i.e. for the first time
always ask for permission, the user either explicitly allows or
explicitly "ignores", for once or all).

Permissions will be as follows:

- File-System Permissions

  Each file-system permission has three components [(A, B, C)], that are:

  A. A directory, to which the permission applies, along with all of
its subdirectories recursively;
  B. A list of file extensions, which we are allowed access to;
  C. A list of access types, either "read-only" or "full" (again, we
are simplifying).

  If (C) is set to "full", the program (on which the permission applies)

  - can create new files with a file extension in (B)
  - can create new sub-directories in (A),
  - remove empty directories in (A) (but not the (A) itself),
  - remove files with a file extension that exists in (B).

  File-system permissions of a program cannot be nested (i.e.
(/home/bora, [.htm, .html], read-only) and (/home/bora/Downloads,
[.*], full) cannot co-exist for the same program).

  File-system permissions of a program can be set only for the home
directory of the user or any of its sub-directories (and not for
`/etc` for instance).

- Peripheral Permissions

  Since peripherals are represented as files (e.g. `/dev/video0`) in
GNU/Linux, we can control access to them, again, using AppArmor. In
this case, we would *not* list them as files but peripheral devices
such as:

  - Camera
  - Microphone
  - Locators (GPS, GLONASS, etc.)
  - and so on

- Network Permissions

  As described above, the default action is to notify the user, but
thanks to the `NFQUEUE` we have the option to *interactively* ask the
user for permission than to passively "notify" them. OpenSnitch
<https://github.com/evilsocket/opensnitch> is a great proof of concept
that uses iptables, NFQUEUE, and ftrace to intercept network calls in
real-time. So for instance when you run:

  $ telnet www.google.com 80

  You'll get

  > /usr/bin/telnet wants to connect to 216.58.201.4 on TCP port 80 (http)
  >
  > [ ] Forever
  >
  > Ignore Once        Ignore        Allow Once        Allow

Programs (code) that outside of the "trusted path" (i.e. any directory
that is writable by any non-root user) can still have permissions, but
The Software will verify the checksum of the binary to ensure that it
has not been modified.

The idea is really not that complicated at all, and as you have read,
it's more of a simplification (and unification within the concept of
"permissions for applications") of already-existing solutions to make
them accessible to end-users/desktop-users so that they can protect
themselves against malicious software.

I'd love to hear your feedback, and I would be eternally grateful if
somebody would like to mentor.

Yours,
Bora