since the apparmor profile is disabled by default, please make the apparmor policy strict with option to make less strict

12:54 <rbasak> I believe that's by design.

12:54 <rbasak> Restricting Firefox makes sense, but it destroys considerable functionality. So there's a trade-off.

12:54 <rbasak> If various functional parts of Firefox don't work by default because the profile is too restrictive, then users wouldn't use Ubuntu.

12:55 <rbasak> AFAIK, the profile is not enabled by default anyway for this reason.

12:55 <rbasak> Also the bug is against the wrong package. It's the firefox package that ships the AppArmor profile, not apparmor.

12:55 <rbasak> So I'll move it and flag it as security as that's your concern, and the security team can triage it.

12:56 <rbasak> We have a better way of containing browsers BTW. Use a snap instead. I don't know if there's one for Firefox yet.

12:57 <rbasak> https://blog.mozilla.org/futurereleases/2016/04/21/firefox-default-browser-for-linux-users-ubuntu-new-snap-format-coming-soon/

12:57 <rbasak> "Firefox is the default browser for Linux users on Ubuntu, new snap format coming soon"
12:58 <blackflow> rbasak: no the report is against AppArmor, because the real issue is in the ubuntu-browsers abstraction

12:58 <blackflow> if the profile is not enabled by default, then all the more reason to make it stricter and those users who are aware and explicitly enable it, will have saner defaults

12:58 <rbasak> Oh, fair enough.

12:59 <rbasak> But really, if you care about this stuff, you should look into snaps.

Just a comment about snaps. The snaps would have the same kind of problem, if convenience is a factor.

But most importantly, these security issues should be communicated to the user. If convenience is a critical and important default.

"The [snap|browser] you've just installed is secured against general threats that aim to modify local files or install unwanted software. However, it allows almost unconfined access to the files in your HOME directory, including any sensitive files you might have in your Documents directory. Please take a look at <...> if you wish to further restrict this access."

What about blocking access by default to directories that begin with . (like .config, .cache, etc.) ?

I think that might fix your KeePassX use case but still allow users to use their browser to upload pictures either from their Pictures/ directory or whatever named normal directory in their home directory.

Jeremy,

that would not cover the general access case I was talking about. Please note, this is not a personal bug that I can't solve. I've modified my Firefox profile to address these issues as much as I can (as much as capable but not omnipotent AppArmor can do).

I'm concerned about defaults and communicating the issue to users. I just think that in this day and age, the (in)security situation is so severe that we must no longer consider making systems that "even my grandma can easily use" without also considering a security profile that "even my grandma should be aware of and tweak it because it's simply necessary".

The whole point of M in MAC is, after all, to explicitly grant what is doable in otherwise default-deny context. "@{HOME}/** r" flies in the face of it (and personally I think "owner" should be added there to, despite the fact that DAC is consulted first. Least Privilege Policy.).

I'll admit that I don't know how the snaps interface is designed to work eventually, primarily because it's so new and I haven't had a chance to check every aspect of it. But, if it will be possible to allow a restriction like "no random $HOME access except ~/Downloads and ~/Public" with a switch of a checkbox or snap plug, then it's job well done while balancing usability and security.

Thank you for using Ubuntu and filing a bug!

While /etc/apparmor.d/abstractions/ubuntu-browsers.d/user-files is shipped by apparmor, it is actually /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox that #include's it, and this file is managed by the firefox package, so moving this bug there.

As for what the profile is intended to protect against and why it works the way it does, please see https://wiki.ubuntu.com/SecurityTeam/FAQ#Firefox_AppArmor_profile

This issue was discussed on IRC with the reporter. Here is the summary:
- the firefox profile is disabled by default
- the firefox profile aims for 'usable security' such that if the profile is enabled, the browser is expected to generally work in the manner that people would expect
- the firefox profile can be adjusted to remove the user-files abstraction either by editing /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox or using 'aa-update-browser'

In Ubuntu, we aim for 'usable security' because we don't want people to turn AppArmor off. The intent of the profile is that when enabled, people get some protections (eg, code execution) but can access their files using normal browser workflows. Security-minded individuals can then fine-tune the profile to make it more strict.

Vlad made the point in that if the profile is turned off by default, then it can be made very strict with people adding to the profile what they want. As such, adjusting the bug description and marking as Wishlist.

Note: IMHO snaps will be the way forward with browsers. Upstream is committing to shipping firefox as a snap and that snap will have stricter confinement than the AppArmor profile in the firefox package of Ubuntu currently (eg, stricter AppArmor policy, seccomp, etc). Of course, Mozilla will also want usable security and they will use the transitional 'home' interface which grants access to files in a similar fashion as the 'user-files' abstraction, but security-minded individuals can use 'snap disconnect firefox:home' to further restrict it. The long term goal is that the snap will used on Ubuntu Personal or other distributions and use mir or wayland instead of X and with file choosers that understand the sandbox limitations and work with the OS to avoid using the transitional 'home' interface to provide a very secure usable browsing experience.

Clarification re snaps and the 'home' interface> the 'home' interface does not grant access to toplevel hidden files and directories.

Jamie,

thanks for the elaborate explanation and directing the issue where it matters.

I'd just like to comment on switching the issue to "firefox" package and "the firefox profile can be adjusted to remove the user-files abstraction ..."

Removal of "user-files" abstraction would weaken the security because user-files contains explicit DENY rules for ~/.ssh and kde|gnome wallets, as well as ~/.gpg (!!). While that would, in turn, also imply removal of "@{HOME}/** r" ruleset, and thus imply no access to files in user's HOME directory at all, it would compound with default Firefox' policy of "/**/ r," which would then allow at least listing of all user files.

The user-files abstraction is important. It protects known sensitive files, but it should also deny all access to anything but ~/Downloads and/or ~/Public. With a few comments with which the user can be directed to easily re-enable full @{HOME} access if she or he so desires.

I have created simialr bug in https://bugs.launchpad.net/firefox/+bug/1609439 . It's confusing having too (or more?) Firefoxes in launchpad...

My original issue was that usr.bin.firefox contains kinda.. misinformation, if I may, with rules like:

owner @{HOME}/Downloads/* rw,

while included user-files profile allows all home access (except some denies of course), making this mentioned rule redundant.

Anyway, I agree that profile could be stricter, although question arises, will I be able to suggest it for my not-that-savvy friends of mine, if they would be able to download only to the Downloads, and upload only from, let's say Home maybe (and Downloads and Pubic...)? What a bout cat pics placed anywhere within home or mounted drive or whatever? :) .

About user-files: there is /etc/apparmor.d/abstractions/private-files so maybe it could be improved and used as main deny list, alternative to /etc/apparmor.d/abstractions/ubuntu-browsers.d/user-files ?

Hello.

I think that the default Firefox profile can be made more restrictive, stricter. It's pretty simple and can be done by removing a few default rules (mentioned in bug report by Vlad K., for example) etc. Anyway, here are some ideas (based on testing made in the past).

As an example, we can specify, mentions the rules that makes browsing directories works. My tests made in the past, showed that Firefox needs an access only to '/dev/' directory - not the whole and everything in '/**/' folders! The same thing with rules providing an access to documentation and other files (default rule: '/usr/** r,'). In my testings, Firefox needed an access to '/usr/share/{glib-2.0,hunspell}/' folders only! Not everything under '/usr/'.

If it's about '/etc/apparmor.d/abstractions/ubuntu-browsers.d/user-files' file and rules to access everything in User home folder: by default, Firefox profile contains rules that allows downloads to '~/Downloads' and uploads from '~/Public' folders, right? Because, there is also one rule related to the 'user-files' file: '<abstractions/ubuntu-browsers.d/firefox>' an access is unrestricted.

Changing/removing rules in the 'user-files' file and adding rules that allows User to save files only in '~/Downloads' folder seems to fix such issue - unrestricted access etc. The same thing with unnecessary - in my opinion - rules mentioned above '/**/' and '/usr' and so on.

Additionally, there can be added a '<private-files-strict>' rule to deny access to sensitive files and to provide a special attention to (potentially) executable files. (However, during testings appeared a few "DENIED" entries in the logs files and additional rules were needed.)

And that's not everything. For example, Users who don't use printers doesn't need '<abstractions/cups_*>' rule, right? There are many rules in default Firefox profile that can be changed/removed etc. (Personally, I'm using profile created from scratch, with more stricter policy).

By the way: it seems that with every next Firefox release, a new rules needs to be added. It's happens very often. The latest Firefox version, caused several problems: no menu bar, main window resize, errors with tab, no website could be enabled by clicking on a bookmarks labels etc. Really, the v60 version caused many issues, that required a few new rules. Here are bug report:

● https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1770600

I hope, that it will help someone to fix problems, that may appear after Firefox upgrade to the 60.0 version.

Thanks, best regards.

I think we could really use some kind of conditional construct (IF ... THEN ...) in AppArmor syntax. Everything being talking about here should, ideally, be adjustable using tunables. With a debconf configuration option, even.

Between users who want strict access control to user files, and users who don't know "how to computer," there's no way we're going to get agreement on a default configuration that satisfies the former. The best outcome, then, is to make tightening up the access easy, and editing lines in the guts of profile and abstraction files IMO does not measure up to that.

On Sun, Jul 29, 2018 at 11:35:58PM -0000, Daniel Richard G. wrote:
> I think we could really use some kind of conditional construct (IF ...
> THEN ...) in AppArmor syntax. Everything being talking about here

apparmor_parser does in fact have conditionals of exactly this form. They
aren't documented -- or used -- because the friendly tools don't yet know
how to parse the contents, or suggest changing the value of the booleans
in response to events in the logs.

Some Day. :)

Thanks

Hmmm, interesting!

I wouldn't hold out too long on giving the friendly tools smarts vis-a-vis conditionals, since that kind of logic isn't necessarily straightforward (i.e. can be hard/time-consuming to implement), it's not necessary for power/paranoid users (we're happy resorting to a text editor), and even low-skill users are better served by a debconf prompt anyway.

Could we eventually use xdg-desktop-portal? https://bugzilla.mozilla.org/show_bug.cgi?id=1490186