@Hadmut Danisch:

Please review the Ubuntu Code of Conduct, and cease the personal attacks
immediately:

http://www.ubuntu.com/community/conduct

> > The browser is supposed to be able to read and write files from the user's directory. 
> 
> Technically wrong.
> 
> The browser is supposed to read and write just it's configuration
> files/directory.
> 
> Besides that, the browser is supposed to read and write files from a
> user's directory if and only if the user explictely wants to do so, and
> only those files the user wants to read or write. The browser is
> definitely not supposed to read and write any file in $HOME or /* . I
> don't see where you would take that definition from.
> 
> Especially, the browser is not supposed to read or write files silently
> without user's consent. But that's exactly what happens if under attack.

There is no way to differentiate, in an apparmor profile, which files
the user intended to open, and which files were opened while under
attack in the user's home directory. For users who know in advance which
files they will open, the apparmor profile can be customized.


> > This is *by design* of the browser, in particular firefox. 
> 
> Wrong claim for two reasons.
> 
> The first is: There is no such design and no such task of the browser.
> Show me where that design should be defined.

Simply visiting a website to upload a picture to an online album clearly
illustrates the browser was meant to open files specified by the user.

> The second is: You simply do not understand what security is and means.
> Even if that was a design of the browser, your argument was wrong.
> Because there are attacks and flaws in the browser, and therefore the
> browser accidently or because of attack does something it is not
> designed to do.
> 
> Or in other, more simple words: Let the browser do what it is designed
> for, but use security to prevent it from things it was not designed to.

Reading files from the user's home directory is something the browser
was designed to do.

> 
> For example, the browser is designed to open a requester and to
> inform/ask the user before up-/downloading a file. Silently reading or
> writing arbitrary files without user's consent is definitely against
> firefox' design, so your point is technically wrong.

This is not something that can be enforced with MAC. You should look
elsewhere than Apparmor or SELinux for this type of protection.


> (and btw, even if you take this as a personal attack, but it's something
> that must be said, because that's the main problem: Someone who argues
> the way you do is definitely not competent in IT security. Maybe it
> would be better to pass the security relevant tasks in ubuntu to someone
> else experienced with such problems.)

Please refrain from personal attacks.

> > How else is someone supposed to download a file? To upload their presentation to the company webserver? If the AppArmor profile denied these actions by default, what would the regular user who knows nothing of AppArmor do? 
> >   
> 
> Sorry, but that point is both silly and wrong. I would appreciate if
> you'd remain objective, because in my cultural background it is
> considered as rude argueing that unobjective way.
> 
> a) there is a difference between beeing able to upload a file and beeing
> able to upload any file. There is something between all files and no
> files at all.

How do you make the distinction? How can we restrict which files the
user intended to upload without interfering with what they are trying to
do?

> b) The way you argue would be an argument against any security measure
> at all. Hey, why do you have file permissions at all? Why do you use
> user accounts without root permissions? You should alway run firefox as
> root, because only then you can be sure to be able to upload all files
> you might want. Understand what I am talking about?

I clearly don't, please explain in more detail what you're trying to
illustrate.

> c) What if the presentation is confidential and should not go the
> internet but is silently fetched by hackers?

How would an apparmor profile know that that particular presentation
should _not_ go to the Internet, but the one beside it in the same
directory _should_?


> d) I've never said that the 'default' setting should be to deny. I've
> said that the default settings must be put into a separate file to allow
> the admin to set it to the local needs without interfering with the
> master apparmor file for firefox. Once modifying the
> /etc/apparmor.d/usr.bin.firefox runs you into trouble, because you
> either don't get updates or you have to modify it after every update
> again (please read the docs about ubuntu/debian /etc files).
> 
> The problem is, that you talk about a 'default' setting, but actually
> you are enforcing it to be open, without leaving the local admin a good
> and clean chance to keep it more closed. You are counterfighting
> security. And based on your words, you do not understand the
> requirements of security.

The firefox apparmor profile restricts what firefox can do on the
default desktop, without impacting it's usage. This file can be modified
to add a more restrictive security policy. This is not "counterfighting"
security, it's _adding_ security that can be tightened even more by a
knowledgeable administrator.

In future versions, there will be a way to add local configuration
without modifying the main profile.

> 
> 
> >  * If we were lucky, they would only turn off only the firefox profile (which, I might add is *opt in* only right now). This action would weaken the security stance of firefox since it would now be running totally unconfined.
> >   
> 
> Nonsense. You don't seem to have understood the apparmor.d configuration
> principle as well.
> 
> That's what these abstraction files are made for.
> 
> Put all these configuration lines that are not necessary to run firefox
> itself and just needed for up-/download of files into a separate
> abstraction file and include it. Leave it open by default.

Please contribute by submitting a debdiff of what you're proposing.

> 
> When installing firefox open a dialog to inform the admin, that it is
> open by default and that the admin should change to meet local security
> needs. That's the clean and proper way.

I'm not sure what you mean by "open a dialog to inform the admin". The
firefox profile is disabled by default, and there is documentation to
explain how to enable it and adapt it to local security needs:

https://wiki.ubuntu.com/SecurityTeam/FAQ#Firefox%20AppArmor%20profile

Opening a dialog is definitely not a clean and proper way to handle
this.

> 
> That way you have your default open setting (which is really a default
> and not an enforcement) and allow the admin to set a local policy
> without interfering with or missing future updates.

The default firefox profile enforces restrictions by default. What do
you mean by "not en enforcement"?

> 
> >  * If we were more unlucky, the user would turn off all of AppArmor (this has been seen occasionally with AppArmor but famously with SELinux). The result would be that CUPS, dhclient, evince, the guest-session and other profiles in Ubuntu would be disabled.
> >   
> 
> Again, that's nonsense.

Please visit the mailing lists or forums for countless examples of users
who completely disable apparmor when they have a problem with it.

> 
> 
> You are trying to decide between using apparmor not at all or using it
> the wrong way.
> 
> You have to use apparmor the correct way. The way it was designed to, to
> use your wording. Learn to use it.
> 
> If you argue to use firefox the way it was designed, why is it so
> difficult for you to use apparmor as well the way it was designed?

By "you", do you mean the users who have disabled it?

> >
> > AppArmor can protect against many things. The firefox profile protects against execution of arbitrary code by the browser and reading/writing of files you do not own (eg /etc/passwd), reading/writing sensitive files like the user's gnome-keyring, ssh keys, gnupg keys, history files, swp, backup files, rc files and to files in the standard PATH. It also confines add-ons and extensions to the above. Firefox is integrated into the Desktop and so it must be allowed to open helper programs and access the user's data. The profile is by default *general purpose* with the design being:
> >  * when enabled, it significantly improves the security of firefox as is
> >  * it provides a starting point for people to confine firefox how they want to
> >  * the implementation gives the user the ability to fine-tune it to be as strict as desired
> >   
> 
> you are talking, and talking, but it does not get any better.
> 
> The way you write the profile is not a default, it is effectively an
> enforcement. You are forcing systems into beeing open if the local admin
> does not want to cope with config file after every package update, which
> is unfeasibly.

The apparmor profile, once enabled, restricts what firefox can do. Just
because it doesn't comply to the enforcement required by your local
policy doesn't mean it's too open.

> 
> 
> Sorry to disappoint you. But you are someone who must be personally
> critized, because the problem, the reason is in your person only. You
> simply did not understand how security in common and how apparmor in
> particular works. All your arguments were pointless, and trying to show
> a conflict that does not exist, simply because you do not understand how
> things work.

This is not how the open source community works. Please refrain from
personal attacks.

> 
> And therefore my question what qualified you to deal with such bug
> reports. I don't see the knowledge and experience in IT security
> necessary for that job in your email.

Again, stop with the personal attacks.

> 
> And btw., the way you are offending others without realizing it while
> beeing so easily offended yourself is not helpful.
> 
> 
> Sorry to say that, but I'll cite your mail to prove that ubuntu lacks
> the capacity to deal with security sufficiently.

Because your local security policy requires a more restrictive apparmor
profile than the one that comes by default doesn't mean Ubuntu isn't
secure.

Marc.