Is Cockpit Secure?

1 files changed, 238 insertions, 0 deletions

diff --git a/content/cockpit/security-in-cockpit.md b/content/cockpit/security-in-cockpit.md
new file mode 100644
index 0000000..e196bb6
--- /dev/null
+++ b/content/cockpit/security-in-cockpit.md
@@ -0,0 +1,238 @@
+Title: Is Cockpit Secure?
+Date: 2017-06-15
+Category: Cockpit, Linux
+Tags: cockpit, linux
+Slug: is-cockpit-secure
+
+Security is of your Linux systems vital. It's not a binary thing though.
+Depending on your requirements you end up choosing a level of security that
+still allows you and your systems to accomplish what they need to do.
+
+Here's info about [Cockpit's](http://cockpit-project.org/) security, to help
+you make those choices. You'll find not only has Cockpit got a solid security
+story, but you can use it in all sorts of different ways depending on what
+kind of security your systems need.
+
+## Cockpit is a Linux session in your browser
+
+Let start by stacking the deck against Cockpit. First off it's important to
+remember that Cockpit is actually an alternative Linux session ... along side X11,
+SSH and VT logins. It's a session in the [PAM](http://www.linux-pam.org/),
+[logind](https://www.freedesktop.org/wiki/Software/systemd/logind/), TTY,
+[SELinux](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Confining_Users-Confining_Existing_Linux_Users_semanage_login.html)
+ and other senses.
+The logged in browser and the javascript code it is running can interact directly
+with the system as part of that session.
+
+Try this out if you want. [Log into Cockpit](http://cockpit-project.org/running.html),
+and pop up the Javascript console by pressing *Ctrl-Shift-J* in your browser. Now type
+commands like the following:
+
+    > zz = cockpit.spawn(["ping", "-c4", "8.8.8.8"])
+    > proxy = cockpit.dbus("org.freedesktop.hostname1").proxy()
+    > proxy.KernelName
+
+Pretty cool, huh. And that's why Cockpit can be such a powerful and quick way to build
+Linux system admin interfaces.
+
+## But are browsers secure?
+
+But can we trust browsers with your security? Firefox is about
+[15 million lines of code](https://www.openhub.net/p/firefox/analyses/latest/languages_summary)
+that all have to work together, and after looking at the list of
+[security updates](https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/)
+you gotta think about what that means for your security.
+
+Any management system with a browser interface requires a secure browser.
+That includes
+[Satellite](https://www.redhat.com/en/technologies/management/satellite),
+[Tower](https://www.ansible.com/tower),
+[Foreman](https://www.theforeman.org/),
+[Landscape](https://landscape.canonical.com/),
+[CloudForms](https://www.redhat.com/en/technologies/management/cloudforms),
+[cPanel](https://cpanel.com/) and more. If anything like this interacts with
+your systems, then security bugs in browsers have a direct effect on your
+system security.
+
+Secondly take a look at any browser based tools that were involved in the
+creation or curation of the software installed on your system, including
+tools used by your Linux distribution.
+
+If your security requirements are strict and you must avoid browsers at all
+costs, then be sure to audit all possible places that browsers were involved
+in what's running on your systems. It's harder than you think.
+
+Unless your system is very isolated, it turns out that browsers are
+likely already highly involved in the security paths for your systems.
+Cockpit does not change this situation significantly.
+
+## Cockpit has no special privileges
+
+Back to Cockpit. What does that session look like? Cockpit itself has no
+special privileges. The credentials of the logged in user start a login
+session, and Cockpit can perform exactly the tasks that the logged in user
+has access to. It has no more or less permissions.
+
+You can examine anything about Cockpit security. Log into Cockpit, open the
+*Terminal* page and run commands like the following:
+
+    :::text
+    $ id
+    uid=1000(stef) gid=1000(stef) groups=1000(stef),10(wheel)
+    $ cat /etc/shadow
+    cat: /etc/shadow: Permission denied
+
+If you logged in as a non-root user, you'll find that Cockpit has no
+elevated privileges on the system.
+
+## Escalating privileges
+
+So if Cockpit only has the priviliges of the authenticated user, how does
+it perform admin tasks. Well obviously one could log in as root, and the logged
+in session would have all capabilities and access to the system.
+
+But logging in directly as root is a poor security practice. Cockpit supports
+escalating privileges via [sudo](https://www.sudo.ws/) and/or
+[polkit](https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html).
+If, and only if, the logged in user has permission to escalate privileges.
+
+On the login screen you'll see a checkbox to enable privilege escalation:
+
+![Reuse my password for privileged tasks](images/cockpit-reuse-password.png)
+
+This checkbox allows Cockpit to use your login password to escalate
+privileges via sudo and/or polkit when necessary to perform admin
+tasks. This is as if you log in with SSH and then used ```sudo -s```
+or similar to perform some admin tasks. Try the following command once
+you've logged in with the checkbox:
+
+    :::text
+    $ pkexec bash
+    # id
+    # uid=0(root) gid=0(root) groups=0(root)
+
+You can track the state of this privilege escalation in the upper right
+corner of Cockpit. Click this button to drop any escalated privileges:
+
+![Unlocked option](images/cockpit-unlocked.png)
+
+Now you can again, try the above ```pkexec``` command, and it should fail.
+
+## Principle of Least Privilege
+
+A good security practice is to run services, processes or tools with
+the least amount of security privilege necessary to perform their task.
+To accomplish this, Cockpit is split up in multiple components, each of
+which runs with as little access to the system as possible.
+
+On RHEL, Fedora, Ubuntu, Debian and any other distro that we distribute
+Cockpit for ... we test and make sure that this privilege separation is
+in effect. Including correct SELinux policies, and unprivileged unix users.
+
+Here's some of the privelege separation described:
+
+    stef        9690  ...  Sl  06:08  0:00 cockpit-bridge
+
+The ```cockpit-bridge``` is the part of Cockpit that runs in the login session.
+It is similar to a login shell, in that it runs with the privileges and security
+context of the logged in user. In the above case I logged in as the ```stef``` user.
+If you checked the *Reuse my password for privileged tasks* option on the login
+screen, you might also see this process running as ```root``` in which case
+```pkexec``` or ```sudo``` was used (see above) to escalate privileges.
+
+    root        9947  ...  S   06:10  0:00 /usr/libexec/cockpit-session
+
+The ```cockpit-session``` part of Cockpit is a small binary that performs
+authentication for the logged in user. It uses [PAM](http://www.linux-pam.org/)
+or [GSSAPI](https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html)
+to perform that authentication.  ```cockpit-session``` is installed setuid,
+in such a way that it can be launched by the unprivileged ```cockpit-ws``` user
+(see below) during user login. This process performs limited tasks, and has a
+restrictive SELinux ```cockpit_session_t``` context. Lastly is a reasonably short
+program written in plain C so it is easier to audit.
+
+    cockpit-ws 11295  ...  Ssl 06:14  0:00 /usr/libexec/cockpit-ws
+
+This is the component that listens on the network. It hands off
+authentication information to the ```cockpit-session``` to perform a login
+and launch cockpit-bridge. The ```cockpit-ws``` binary runs as an
+unprivileged unix ```cockpit-ws``` user, with a restrictive
+SELinux ```cockpit_ws_t``` policy.
+
+## Security Policy within the browser
+
+Cockpit runs javascript code from the system it's logged into. Obviously that
+code is protected by the standard
+[Same Origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)
+that web browsers adhere to.
+
+But How does Cockpit protect against bugs in the code. How can we be sure that
+only the javascript code installed on the system is run, and bugs are not
+exploited to run code trojaned into logs or other data loaded by Cockpit?
+
+Browsers have a security technology called
+[Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
+which is sorta like SELinux or Apparmor in your browser. The policy describes
+exactly where code can be loaded, what can be run, and what sorts of connections
+can be made by the browser.
+
+In Cockpit's case we send a strict ```Content-Security-Policy``` header that
+only allows code installed in Cockpit packages on the logged into system to be run.
+Although individual parts of Cockpit can
+[override this default](http://cockpit-project.org/guide/latest/packages.html#package-manifest),
+it's rarely done. The default security policy looks like this:
+
+     Content-Security-Policy: default-src 'self' connect-src 'self' ws: wss:
+
+A failure of *Content Security Policy* will look something like this in your browser's
+javascript console:
+
+![Content Security Policy denial](images/csp-denied.png)
+
+## Security of the network facing TCP port
+
+Cockpit typically listens on TCP port 9090 on a host. This is the
+[websm or "Web Systems Manager" network port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt).
+Opening a network facing port has security risks. Both the exposed surface
+area and stuff listening on that port, in this case ```cockpit-ws```, are risky.
+
+If this is an issue for your systems, you can use Cockpit over the SSH port
+already have open. But wait, how does that work? Browsers don't natively speak
+the SSH protocol, and getting a browser to do so would be an impressive party trick.
+
+To use Cockpit over SSH, use a *bastion host model*: Start ```cockpit-ws``` on port 9090
+on a single host, perhaps even your localhost. Connect to that with your
+browser and use that first Cockpit instance to log into to Cockpit on other machines
+others over SSH. If you draw it up, it looks something like this:
+
+![Multi-host Transport](images/transport-multi-small.png)
+
+[Atomic Host includes Cockpit by default](http://www.projectatomic.io/docs/cockpit/),
+in this way. Atomic Host doesn't include ```cockpit-ws``` or open port 9090 by default,
+but expects you to connect from another running Cockpit instance over port 22. There's
+also the possibility to run ```cockpit-ws``` as a container to accomplish this.
+
+When you're trying this out in real life, specify an alternate server on the Cockpit
+login screen. The SSH protocol will be used to connect to it:
+
+![Login Alternate Server](images/cockpit-login-alternate.png)
+
+Or you can add other machines to a local dashboard, and Cockpit will connect to
+them via SSH. Even usage of SSH key based authentication works great:
+
+<iframe width="853" height="480" src="https://www.youtube.com/embed/Ye5YlVNXC9w" frameborder="0" allowfullscreen></iframe>
+
+Obviously, when you use Cockpit over SSH, it's not just a real Linux session,
+it's also an SSH session in every way. Try it out.
+
+## In conclusion
+
+I could go further about how Cockpit uses
+[Kerberos to do single sign on](http://cockpit-project.org/guide/latest/sso.html)
+or [how it works with certificates](http://cockpit-project.org/guide/latest/https.html)
+or how you can even bring
+[your own authentication tool](https://raw.githubusercontent.com/cockpit-project/cockpit/master/doc/authentication.md)
+to replace ```cockpit-session```. and much, much more.
+
+But suffice it to say, that Cockpit's security is well thought out, layered and
+matches that of Linux in general.