common policy about apparmor.d HOT 13 CLOSED

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.

from apparmor.d.

• 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

from apparmor.d.

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.

from apparmor.d.

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

from apparmor.d.

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?

from apparmor.d.

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

from apparmor.d.

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

from apparmor.d.

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

from apparmor.d.

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?

from apparmor.d.

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.

from apparmor.d.

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

from apparmor.d.

For now let's keep /usr/share

from apparmor.d.

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?

from apparmor.d.