[lxc-devel] [PATCH 2/2] apparmor: restrict signal and ptrace

[Stéphane Graber]

On Thu, Sep 25, 2014 at 02:47:08PM +0000, Serge Hallyn wrote:
> restrict signal and ptrace for processes running under the container profile.
> Rules based on AppArmor base abstraction. Add unix rules for processes running
> under the container profile.
> 
> Author: Jamie Strandboge <jamie at canonical.com>
> Signed-off-by: Serge Hallyn <serge.hallyn at ubuntu.com>
> ---
>  config/apparmor/abstractions/container-base.in | 36 +++++++++++++++++++++++---
>  1 file changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/config/apparmor/abstractions/container-base.in b/config/apparmor/abstractions/container-base.in
> index 096d35b..0aee5ee 100644
> --- a/config/apparmor/abstractions/container-base.in
> +++ b/config/apparmor/abstractions/container-base.in
> @@ -3,11 +3,39 @@
>    file,
>    umount,
>  
> -  # The following 3 entries are only supported by recent apparmor versions.
> -  # Comment them if the apparmor parser doesn't recognize them.
> +  # dbus, signal, ptrace and unix are only supported by recent apparmor
> +  # versions. Comment them if the apparmor parser doesn't recognize them.
> +
> +  # This also needs additional rules to reach outside of the container via DBus, so
> +  # just let all of DBus within the container.
>    dbus,
> -  signal,
> -  ptrace,
> +
> +  # Allow unconfined to signal us
> +  signal (receive) peer=unconfined,
> +  signal (receive) peer=/usr/bin/lxc-start,

What are we trying to prevent here?

To me it seems like we're encouraging LXC API users NOT to write
apparmor profiles for their code as otherwise they'd be unable to send
signals to the container.

> +  # Allow us to send signals to ourselves
> +  signal peer=@{profile_name},
> +
> +  # Allow other processes to read our /proc entries, futexes, perf tracing and
> +  # kcmp for now (they will need 'read' in the first place). Administrators can
> +  # override with:
> +  #   deny ptrace (readby) ...
> +  ptrace (readby),
> +
> +  # Allow other processes to trace us by default (they will need 'trace' in
> +  # the first place). Administrators can override with:
> +  #   deny ptrace (tracedby) ...
> +  ptrace (tracedby),
> +
> +  # Allow us to ptrace ourselves
> +  ptrace peer=@{profile_name},

The above is a whitelist so it's hard for me to know what actually ends
up being blocked, can you elaborate on that?

> +  # Allow unconfined processes to us via unix sockets
> +  unix (receive) peer=(label=unconfined),
> +
> +  # Allow all unix in the container
> +  unix peer=(label=@{profile_name}),

So those two are still bothering me.

You said that those aren't going to block anything so long as we have fs
access to the socket, but I'm not seeing what in the above rules
guarantees that.

The way I read the above is that we're allowed to talk over a unix
socket to a process which is unconfined or to a process which is running
under the same profile we are.

But doesn't that mean that if we were to say, create a profile for
cgmanager, access to the cgmanager socket will then be blocked?
If so, that means that with this change, I'm no longer allowed to
bind-mount and use a mysqld socket since I believe mysqld runs under
apparmor and so won't fit the above.


Overall, I still see a lot of potential problems for very little benefits.

>  
>    # ignore DENIED message on / remount
>    deny mount options=(ro, remount) -> /,
> -- 
> 2.1.0
> 
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140926/d68d1146/attachment.sig>