Rather than discussing the issue, you also speak of me being an American and all the ignorance that that brings, my qualifications for working in security, and accuse me of ignoring your arguments. I did not reciprocate, but instead, attempted to answer the points at hand. You also quoted me out of context: "I'll put your personal attack aside". I actually said "I'll put your personal attack aside and address your point as I think your main question is valid." I am not ignoring your point regarding *this bug*, I am choosing not to engage you in your attacks.
After responding to your report, I later marked the bug as "Won't Fix" as opposed to "Invalid" as I recognize that your point is not invalid. In other words, I was open to your criticism of the profile and recognized my mistake at marking it invalid. For whatever reason, we seem to not be communicating effectively, which is a shame. However, I will one more time try to address your points in order: > > 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. This URL is counter to your argument: files:///home/<username>. Web browsers have long been able to be used as a file browser so that people can navigate to the files they need access to for uploads or editing (consider add-ons for web development). > 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. I agree with that, but a security protection such as DAC or a MAC system cannot know what files a user wants to have access to. It must be *configured*. DAC in Ubuntu is configured with 755 home directories (for historical reasons and which may change in a future version) with read/write access to $HOME. Since Ubuntu does not want to break a user's browser, the profile by default allows a user access to her files. AppArmor doesn't know if it is a user accessing the files, or the process due to an exploit. We can only confine the process, so unless we want to drastically impact usability, we cannot *by default* have a too strict profile (see below for more on this). It is recognized that the profile does not meet the needs of everyone, which is why the profile is a configuration file that people can edit however they wish. You are forgetting that shipped files in /etc are not overwritten on upgrades. To the contrary, dpkg is very careful about changes made to files in /etc and will prompt the user for when there are changes. It is recognized that there are usability problems with this (see below). > 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. Again, the "file://" URL is one such indication. So is the Open file dialog and the Save As dialog. All (and likely many more) are indications that the browser is supposed to be able to read and write files. With regard to the browser, DAC in general enforces writing only to $HOME. Browsers that run on Unix understand what it means to be confined by DAC, and therefore have a concept of $HOME, which is why they put their files somewhere under $HOME. The AppArmor profile extends that concept and gives access to $HOME, while restricting access to especially sensitive items in $HOME. > 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. Of course it isn't supposed to. Of course this happens in an attack. As I have stated several times, the profile does not attempt or claim to protect against this in a perfect way. It prevents against reading and writing particularly sensitive files, which attempts to strike a balance between usability and security. >> 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. See file:// and various file dialogs. > 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. Of course. This is an ideal and perfect implementation. That cannot be achieved with the current technologies. Because AppArmor confines processes, one cannot create a profile that says it is ok to upload $HOME/work/presentation.odp because the user clicked a link in her company's file sharing application (which then firefox would prompt with a file chooser to pick the file) and to deny access when a malicious web application tries to access the same file. That would require changes to firefox itself which is outside the scope of the AppArmor profile anyway (and probably wouldn't work too well in practice anyway). So we are then left with doing nothing, confining firefox in a generally usable manner, or confine firefox in a very strict manner. The choice made here is to have an option to confine firefix in a generally usable manner with the option to finetune confinement. >> 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. Of course there is, but there is not a way to protect against this *by default* with an AppArmor profile without making changes to firefox, or being too strict about permissions (see above). > 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 understood you all along. The browser understands how to work under DAC. The user understands DAC. The browser and the user may/do not understand working under a MAC. > c) What if the presentation is confidential and should not go the > internet but is silently fetched by hackers? See point 'a' above. > 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). I missed this point and I apologize for that. You did say that the profile was grossly negligent because it was too lenient and that very clearly implies that the default settings are wrong, which is what I addressed in previous comments in this bug. That said, this point will be addressed in Ubuntu 10.10, as I already brought it up as an improvement at our Ubuntu Developer Summit (UDS) last month. The idea is to create a 'local' abstraction that is a Debian config file, not a conffile, and therefore does not get in the way of upgrades, but also will not get overwritten. There are also going to be improvements for enabling/disabling helper applications, plugins and privacy settings. > 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. This is wrong. The default is to not have the profile enabled. If you enable the profile, you get a profile default. The profile is not forced open when in enforcing mode because it can be adjusted by an admin to make it more closed. It is recognized that this could be made easier, as I mentioned above and at the last UDS. >> * 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. I think you aren't realizing what real people do when faced with a too strict security mechanism. I see the bug reports where people say the workaround is to turn off the profile or all of AppArmor. Of course education is involved, but human nature is such that if something is in their way when they need to get their work done, they choose to get their work done as quickly as possible rather than seeking an education on the finer points of securing their system. Of course, some people do it the right way, but many, many more do not. Even if the profile already implemented your concept of putting these sorts of things in abstractions, the user still needs to know about AppArmor and how to manipulate the abstractions. > 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. This is *a* way to do it. However, in Ubuntu it is preferred to make a decision about a default that works for most people, and then let more knowledgeable users/admins configure their systems how they want to. It is recognized that profiling a browser is difficult, and likely to cause problems, so the profile is currently opt-in. Popping up a security dialog is not something we want to do in Ubuntu for initial configuration (which would affect *all* desktop installations since firefox is the default browser in Ubuntu, Kubuntu, Xubuntu, etc) because the vast majority of users would not really know what they are doing with regard to configuring AppArmor, and would more than likely choose the equivalent of "Yes, I want to be more secure", which would likely break their browser without knowing how to fix it. The installer can't provide the necessary education about AppArmor required to allow the average user to make the correct decision for them and to know how to problems with her choice. As mentioned, there will be improvements for this in Ubuntu 10.10 by using a local abstraction that won't be touched on upgrades and allowing debconf preseedable options for plugins, etc. This will allow an admin to finetune the browser at install time and even provide a local configuration file option to be used in there configuration tool of choice (eg, puppet). > > * 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. No, it isn't. See bug reports against AppArmor as well as the Ubuntu forums, then look at RedHat's use of SELinux in earlier versions. Many, many people are now 'trained' to turn off SELinux as part of their troubleshooting. Sad, but true. > 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. I don't see how this is true. The profile is shipped as a file in /etc that people can adjust as they want. There is nothing in there that can't be commented out or prefaced with 'deny' or 'audit deny'. Yes, we could have used an abstraction for local changes, and this will be addressed, but this doesn't mean that the profile is 'forced open'. If you don't want to use the profile as shipped, adjust it. Look, the bottom line is that AppArmor as applied to Ubuntu *must* take into account the end user and usability requirements. The browser cannot be broken in the default install. Broken in Ubuntu is generally defined as functionality exposed in an application not meeting user expectations. During install, the user must not be prompted with all kinds of questions (security or not) that he may not understand how to answer. The profile is not shipped in enforcing mode by default yet because it is in development, partly because of the issues you and I have discussed, among others. * Is it the design of firefox to have access to files in $HOME? We agree to 'yes', assuming it is what the user intends. However, AppArmor does not allow for making an educated decision since it is confining a process, so a choice must be made: allow or deny. Whether you and I agree on whether or not the browser should have access to files in $HOME doesn't matter, this is an expectation of the user, and therefore that must be addressed in profiling * Can the profile be more secure/strict? Yes, and we agree on that. We do not seem to agree on default policy, but then, that was understood at profile design and why it is a configuration file that people can edit, whose changes are honored on upgrades * Can the profile be made easier for admins and users to configure? Yes, and we agree on that (as I said I already brought this up weeks ago at UDS) * Should users be more educated? Yes, and we agree on this. This should not happen at install time though, but we are working on improving documentation and awareness. -- firefox apparmor profile is too lenient https://bugs.launchpad.net/bugs/592121 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
