confined role account #1

Description

This charm lets members of certain groups sudo
to a role account confined by an apparmor profile.


Confined Role Account

This subordinate charm can be used to grant members of a given group read-only
access (with optional restrictions on other files as needed) to a specific role
account on an instance.

Let's take a look at how you'd deploy our confined-role-account subordinate
charm in practice. In our example, we're going to deploy MediaWiki and MySQL,
manually add an unprivileged user account on the MediaWiki server, and then
configure the confined-role-account subordinate charm so that our unprivileged
user can sudo to the www-data user, but with restricted access.

First of all, configure your juju environment and fire up the bootstrap
instance.

Then, deploy your charms into the environment:

juju deploy cs:charms/trusty/mediawiki
juju deploy cs:charms/trusty/mysql
juju add-relation mysql mediawiki:db

Now let's manually create our unprivileged user. In a production environment
we'd likely have a different means of doing this, such as via ldap.

juju ssh mediawiki/0
$ sudo adduser service-user

Now we can confirm that we can login as the account in question and see what
sudo permissions it has by default:

juju ssh mediawiki/0
$ sudo su - service-user
$ sudo -l
Sorry, user service-user may not run sudo on juju-env-machine-1.

Now we can deploy the confined-role-account subordinate charm, set our config
options for it, and add a relation to the mediawiki charm:

juju deploy cs:~confined-role-account-charmers/confined-role-account
juju set confined-role-account group=service-user role-account=www-data extra-apparmor-rules="  audit deny /etc/mediawiki/AdminSettings.php r,"
juju add-relation mediawiki confined-role-account

What is this doing? It's saying that anyone in the service-user group can sudo
to the www-data role account with the default read-only permissions, but also
with /etc/mediawiki/AdminSettings.php not visible to them. This file contains
the database password, and in our scenario we want to allow developers access
to the mediawiki server as the www-data role account without giving them access
to the production database password.

And now let's confirm how things look:

juju ssh mediawiki/0
$ sudo su - service-user
$ sudo -l
Matching Defaults entries for service-user on juju-canonistack-machine-1:
    env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User service-user may run the following commands on juju-canonistack-machine-1:
    (www-data) NOPASSWD: /usr/local/sbin/apparmor-wrapper-service-user-www-data \"\"
$ sudo -u www-data /usr/local/sbin/apparmor-wrapper-service-user-www-data
$ echo "this is a test" > ~/this-is-a-test.txt
bash: /var/www/this-is-a-test.txt: Permission denied
$ head /etc/mediawiki/LocalSettings.php
<?php
$path = array( $IP, "$IP/includes", "$IP/languages" );
set_include_path( implode( PATH_SEPARATOR, $path ) . PATH_SEPARATOR .
get_include_path() );

require_once( "$IP/includes/DefaultSettings.php" );

# If PHP's memory limit is very low, some operations may fail.
# ini_set( 'memory_limit', '20M' );

if ( $wgCommandLineMode ) {
$ head /etc/mediawiki/AdminSettings.php
head: cannot open '/etc/mediawiki/AdminSettings.php' for reading: Permission denied

We can also see our command history in /var/log/apparmor-wrapper/www-data-history.log:

echo "this is a test" > ~/this-is-a-test.txt
head /etc/mediawiki/LocalSettings.php
head /etc/mediawiki/AdminSettings.php

Configuration

role-account
(string) The role account that members of GROUP can transition to.
group
(string) The group that can transition to the role account.
extra-apparmor-rules
(string) Extra rules to add to the generated profile.