common policy

[beroal]

Hi. I'm new to AppArmor. Writing a profile surely requires profound knowledge of Linux internals. Reading your profiles was of great help to me. Is there a written approach of dealing with permissions (what is acceptable and what is not) adopted by this repository? Examples of what I mean:

• /etc/machine-id. On one hand, it can be used to track a computer. On the other hand, I believe, there are plenty of ways to track using writing access to common cache directories.
• Consoles. AFAIK, a program having access to consoles can read from all consoles, not just its own stdin. Hence it will be able to read a password, for example.
• dconf. I see many GUI programs require it. This is a configuration server like Windows Registry. Does the access to dconf gives a way to modify other programs' settings? That would be unacceptable. Configuration files don't have this vulnerability.

Knowing your policy will be useful if I ever contribute to your repository and for writing my own profiles.

[roddhjav]

Hi.

There is no written approach of dealing with permissions. I can only see of a few rules:

1. As these are mandatory access control policies only what it explicitly required should be authorized. Meaning, you should not allow everything (or a large area) and blacklist some sub area.
2. A profile should not break a normal usage of the confined software. It can be complex as simply running the program for your own use case is not always exhaustive of the program features and required permissions.
3. Try to respect the profile guideline: CONTRIBUTING.md, and have a look at the links at the end of this file too.

Regarding machine-id and dconf, the first thing is that most of the time denying them would break the normal use of the software, so you just can't.

More generally, for machine-id, this is an example of privacy feature that is simply not provided by a MAC policy as it can restrict the access of a file, not change its content. If you care about it, it is common to use the machine-id shared across all the anonymity distribution such as Tail and Whonix. See https://github.com/Whonix/dist-base-files/blob/master/etc/machine-id

[beroal]

Regarding machine-id and dconf, the first thing is that most of the time denying them would break the normal use of the software, so you just can't.

Should we use the dconf abstraction?

[roddhjav]

Yes, when available you should always use abstraction anyway. Now, a few profile require more than what is in the dconf abstraction so both abstraction and in-line rules are used.

[nobody43]

• It's also possible to regenerate the id on boot:

# rm -f /etc/machine-id
# rm -f /var/lib/dbus/machine-id
# dbus-uuidgen --ensure=/etc/machine-id
# dbus-uuidgen --ensure

I don't have a service file at hand though.

• It seem we don't have dconf key:pair granular control yet:

https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorGSettings
https://marc.info/?t=143274749300002

[roddhjav]

It's also possible to regenerate the id on boot:

From an anonymity stand, it is be more interesting to share the same id across all Linux user that generate a new unique one every time.

[beroal]

Is it important to use GPL-2.0-only for contributions? Why not GPLv3? I'm no lawyer; I just trust Richard Stallman.

[roddhjav]

It has this license because it is initially based on another project (https://gitlab.com/morfikov/apparmemall) that is GPL2 licensed.

[roddhjav]

Also it is the same license than apparmor itself including the "official" apparmor profiles. So it makes it easier to upstream the work.

[beroal]

There are many command line programs. In principle, users can execute them in a wrapper that gives anonymous pipes to a command line program. (Actually, it's what I'm doing on my computer.) This way, we don't need to grant the access to terminal device files to every program. The interaction of GUI programs with the terminal is even more limited: they just print error and debug messages to stdout/stderr.

• Is any type of isolation of programs from the terminal planned?
• What should I write in profiles in the meantime? Should I add abstractions/consoles, say, to a profile for date?

[roddhjav]

I did not work on this specific question yet. So I do not know what is the best way to process (recommendation are welcome). However, there is always the trade off of security vs program breakage. For instance, we cannot assume the program are launch from a wrapper because that would most likely break a lot of program. So for now, the consoles abstraction is the solution.

[beroal]

Should I use /usr/share or @{system_share_dirs}?

[roddhjav]

For now let's keep /usr/share

[beroal]

GVFS. You said in #63 that we should deny the following permission.

owner @{user_share_dirs}/gvfs-metadata/{,*} r,

Without this permission, Evince floods the kernel log and Evince doesn't remember the last position in the document. I conclude that this is expected from the information I found on GVFS.

I suppose this is a common issue. What's the plan on this? AppArmor rules for GVFS which restrict access via GVFS to specific files?