Chrome OS und Browser (Teil 1)
Mittwoch, 1. Februar 2012
Eine Übersetzung für diesen Text ist nicht verfügbar. Bitte wählen Sie die englische Version.
During the last years Google's WebKit-based browser Chrome from the Chromium software project has become
increasingly popular. This article focuses on the inherent security design of the user agent and its interaction
with the underlying OS.
The Linux kernel used in (most unixoid operating systems) every single GNU/Linux distribution, including Chrome OS, inherits the traditional UNIX semantics which consists of two basic levels for process execution, file system object permissions and thus access restriction, namely "root" and "non-root". Thereby root processes are allowed to do nearly everything on the system, whereas non-root processes are limited in their executional behavior [1]. Without architectural concepts like MAC (Mandatory Access Control) this is the way one has to run software on such an RBAC (Role Based Access Control) based system. That seems to be a simple solution to most use-cases regarding process execution and object access restriction, but it also means that any given program which requires a high level of privileges (root privileges) must be made root. That can ether be achieved by direct execution with root privileges or e.g. by execution as a different user using Dennis Ritchie's disputable SUID mechanism [2].
The Linux kernel used in (most unixoid operating systems) every single GNU/Linux distribution, including Chrome OS, inherits the traditional UNIX semantics which consists of two basic levels for process execution, file system object permissions and thus access restriction, namely "root" and "non-root". Thereby root processes are allowed to do nearly everything on the system, whereas non-root processes are limited in their executional behavior [1]. Without architectural concepts like MAC (Mandatory Access Control) this is the way one has to run software on such an RBAC (Role Based Access Control) based system. That seems to be a simple solution to most use-cases regarding process execution and object access restriction, but it also means that any given program which requires a high level of privileges (root privileges) must be made root. That can ether be achieved by direct execution with root privileges or e.g. by execution as a different user using Dennis Ritchie's disputable SUID mechanism [2].
However in a perfect world any given piece of software would simply be written (Kernel-) capability-aware, and thus
not only make use of arbitrary, lightweight Linux capabilities, and drop all the unnecessary ones early in the code,
but abandon the concept of direct execution with high privileges, or the anachronistic SUID mechanism with its
inappropriate file permissions, altogether. For obvious reason it is a dangerous approach to extend the permissions
of a whole binary (which then becomes a process at runtime) just to enable it to perform a single task which
actually requires high privileges. It is truly a potential security hazard, because any kind of malware executed,
or arbitrary flaws within a given program, could cause severe damage to the underlying operating system or otherwise
compromise its integrity and trustworthiness. Nevertheless this unfortunate concept is effectively being used in a
good portion of the current operating systems including most GNU/Linux distributions (TCSEC C2/ITSEC m/ITSK F2)
[3].
Regarding Chrome one can see the following listing on the file system for the browsers main executable: <size> -rwxr-xr-x 1 root root <date> /usr/bin/chromium-browser. Thus Chrome would run within the security context of the caller (which is good) since there is no SUID-/SGID-Bit bit set. Note however that file owner and group are actually set to root. That is one thing the authors of this article criticize about the current versions of Google's popular web browser. Fortunately Chrome makes at least use of modern Kernel capabilities; a fact one may realize early when attempting to write an AppArmor profile for the binary, simply to put it in a walled garden [4]. Therefore the initial use of sys_chroot as well as sys_admin, chown, setuid, setgid and fsetid, which obviously arises from the design concept of Chrome's sandbox, makes perfectly sense. However using these capabilities without getcap/setcap to drop privileges early in the code is not a good idea. We and Mr. Dan Walsh from danwalsh. livejournal.com also realized, when writing an SELinux profile, that execmem was required which is a potential security hazard just as well [5].
As already mentioned before any given binary should, besides avoiding the SUID mechanism, which Chrome does in a special way, drop unnecessary rights/capabilities or not even use them in the first place. Chrome does that partially, but at the same time requires access to large portions of the file system hierarchy to perform its operations – quite devastating in case users home directories contain sensitive information. Among some less important ones access to the following files or directories is mandatory: dash (ixr), mktemp (ixr), readlink (ixr), /etc/ (r), /opt/** (r), /proc/*/ (r), /tmp/* (rw). One may now state the question whether all that is really necessary. Jut in case the browser is compromised, the attacker could less easily exploit possible local root holes on the attacked machine, in case neither large portions of kernel capabilities nor the aforementioned file system permissions were required at all.
According to an article on madore.org by David A. Madore, all root processes have all capabilities and all non-root processes have none: whenever an executable is execve()'d as root, it gains all capabilities, and whenever it is execve()'d as non-root, it loses all of them [6]. That in turn means without enforcing an AppArmor profile on the Chrome binary it could do even more than what's listed above, since one could run a given program with more capabilities than already implemented/used by the author of a program. The problem with Chrome in context is, that there are some really dangerous capabilities beneath the minimum required ones in place already. That makes most applied MAC profiles using AppArmor or SELinux a bit useless, as soon as the profile is too permissive. It is unfortunate that Chrome does not reduce the number of capabilities and therefore the number of privileges but relies on users analyzing the programs behavior and enforce restrictions on it which ultimately won't solve the (underlying) problem [7].
Since the aforementioned is a problem inherent in Chrome's code design, we at TRON-DELTA.ORG recommend to consider possible negative effects of using Chrome within environments with demands for higher security. Even with more restrictive technologies like SELinux, which would lead to a more granular control regarding the software's permissions (file system access, networking, etc.), some of these problems cannot be solved right away except by rewriting the software. Some endeavors in this area include the rejection of the chroot-jail and the use of an SELinux compile-time flag for Chrome. However the outer Chrome itself still needs access to pretty much everything on the system. Also SELinux cannot solve potential problems with the too permissive setexec functionality regarding the use of shared memory. In the end SELinux and AppArmor win over Chrome's native chroot mechanism though. In case no system security enhancement is available it is strongly recommended to jail the software with on-board system tools and apply a maximum-security configuration [8].
Read more on this in the next part of the series "Chrome OS and Browser". In that we will focus on the Chromium project design documents, discuss the German BSI's (Federal Agency for Security in Information Technology) statement about Chrome and also review some design concepts of alternative user agents.
Regarding Chrome one can see the following listing on the file system for the browsers main executable: <size> -rwxr-xr-x 1 root root <date> /usr/bin/chromium-browser. Thus Chrome would run within the security context of the caller (which is good) since there is no SUID-/SGID-Bit bit set. Note however that file owner and group are actually set to root. That is one thing the authors of this article criticize about the current versions of Google's popular web browser. Fortunately Chrome makes at least use of modern Kernel capabilities; a fact one may realize early when attempting to write an AppArmor profile for the binary, simply to put it in a walled garden [4]. Therefore the initial use of sys_chroot as well as sys_admin, chown, setuid, setgid and fsetid, which obviously arises from the design concept of Chrome's sandbox, makes perfectly sense. However using these capabilities without getcap/setcap to drop privileges early in the code is not a good idea. We and Mr. Dan Walsh from danwalsh. livejournal.com also realized, when writing an SELinux profile, that execmem was required which is a potential security hazard just as well [5].
As already mentioned before any given binary should, besides avoiding the SUID mechanism, which Chrome does in a special way, drop unnecessary rights/capabilities or not even use them in the first place. Chrome does that partially, but at the same time requires access to large portions of the file system hierarchy to perform its operations – quite devastating in case users home directories contain sensitive information. Among some less important ones access to the following files or directories is mandatory: dash (ixr), mktemp (ixr), readlink (ixr), /etc/ (r), /opt/** (r), /proc/*/ (r), /tmp/* (rw). One may now state the question whether all that is really necessary. Jut in case the browser is compromised, the attacker could less easily exploit possible local root holes on the attacked machine, in case neither large portions of kernel capabilities nor the aforementioned file system permissions were required at all.
According to an article on madore.org by David A. Madore, all root processes have all capabilities and all non-root processes have none: whenever an executable is execve()'d as root, it gains all capabilities, and whenever it is execve()'d as non-root, it loses all of them [6]. That in turn means without enforcing an AppArmor profile on the Chrome binary it could do even more than what's listed above, since one could run a given program with more capabilities than already implemented/used by the author of a program. The problem with Chrome in context is, that there are some really dangerous capabilities beneath the minimum required ones in place already. That makes most applied MAC profiles using AppArmor or SELinux a bit useless, as soon as the profile is too permissive. It is unfortunate that Chrome does not reduce the number of capabilities and therefore the number of privileges but relies on users analyzing the programs behavior and enforce restrictions on it which ultimately won't solve the (underlying) problem [7].
Since the aforementioned is a problem inherent in Chrome's code design, we at TRON-DELTA.ORG recommend to consider possible negative effects of using Chrome within environments with demands for higher security. Even with more restrictive technologies like SELinux, which would lead to a more granular control regarding the software's permissions (file system access, networking, etc.), some of these problems cannot be solved right away except by rewriting the software. Some endeavors in this area include the rejection of the chroot-jail and the use of an SELinux compile-time flag for Chrome. However the outer Chrome itself still needs access to pretty much everything on the system. Also SELinux cannot solve potential problems with the too permissive setexec functionality regarding the use of shared memory. In the end SELinux and AppArmor win over Chrome's native chroot mechanism though. In case no system security enhancement is available it is strongly recommended to jail the software with on-board system tools and apply a maximum-security configuration [8].
Read more on this in the next part of the series "Chrome OS and Browser". In that we will focus on the Chromium project design documents, discuss the German BSI's (Federal Agency for Security in Information Technology) statement about Chrome and also review some design concepts of alternative user agents.
References:
- ↟ "LPI Linux Certification in a Nutshell"↗. O'Reilly Media, Inc. / S. Pritchard, B. G. Pessanha, N. Langfeldt, J. Stanger, J. Dean. Retrieved 01 February 2012.
- ↟ "Introduction to Linux - 4.1.6. SUID and SGID"↗. Machtelt Garrels. Retrieved 01 February 2012.
- ↟ "Common Criteria for Information Technology [..]"↗. Wikipedia / U. Moser, T. M., N. Tekampe, et al. Retrieved 01 February 2012.
- ↟ "AppArmor v2.1 Chromium Browser Profile"↗. TRON-DELTA.ORG (NGO) / M. H. / PASTEBIN | #1 paste tool since 2002. Retrieved 01 February 2012.
- ↟ "Google Chrome Policy"↗. Dan Walsh's Blog - Got SELinux?. / D. Walsh. Retrieved 01 February 2012.
- ↟ "A new capabilities patch for Linux"↗. madore.org / David A. Madore. Retrieved 01 February 2012.
- ↟ "LCA: Bruce Schneier on the two sides of [..]"↗. Eklektix, Inc. / LWN.net. Retrieved 01 February 2012.
- ↟ "The Ultimate Guide to Secure your [..]"↗. CSIS Security Group. / A. Neagu. Retrieved 01 February 2012.
Zuletzt aktualisiert (Mittwoch, 1. Februar 2012)
