syncdaemon should have AppArmor profile

[Kees Cook]

Binary package hint: ubuntuone-client

Since the syncdaemon should only be accessing files in a very specific location, I would like to see an AppArmor profile created for it by default to make sure it cannot be subverted or at least protect the rest of my files from it.

ProblemType: Bug
Architecture: amd64
Date: Fri Feb 26 00:21:13 2010
DistroRelease: Ubuntu 10.04
Package: ubuntuone-client 1.1.2-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-14.20-generic
SourcePackage: ubuntuone-client
Uname: Linux 2.6.32-14-generic x86_64

[Kees Cook (kees)]

Here's a profile that works for me -- likely will need to be tuned for new user directory creation, but that should be trivial.

This should ship in the package in /etc/apparmor.d and gain the appropriate maintainer-script stanzas to activate the profile on install. For more details see:
https://help.ubuntu.com/community/AppArmor#Creating%20a%20new%20profile

[Elliot Murphy (statik)]

Hi Kees, this is a great idea, and thank you for creating the initial profile! I believe this initial profile is too restrictive, as in Lucid users can tell the syncdaemon to manage any folder in their home directory. Would it be appropriate to give syncdaemon access to everything in the users home directory, or is something more complex needed for that case?

[Kees Cook (kees)]

Ah, I didn't see anywhere to configure the syncdaemon, so I was hoping it
was just the "Ubuntu One" directory.

It could be made to r/w the entire home directory, but that defeats the
purpose a bit (for me). Feel free to adjust as needed, though! It'd
still be nice to have it isolated just to the home directory.

[Kees Cook (kees)]

The profile in the bzr tree won't be sufficient, @{HOME}/* rw, should likely be @{HOME}/** rw, otherwise subdirectories will not be included. It'd be nice if some areas of the home directory were protected (ssh keys, gpg keys, etc) please see the firefox profile for examples.

[Rick McBride (rmcbride)]

On 03/08/2010 02:58 PM, Kees Cook wrote:
> The profile in the bzr tree won't be sufficient, @{HOME}/* rw, should
> likely be @{HOME}/** rw, otherwise subdirectories will not be included.
> It'd be nice if some areas of the home directory were protected (ssh
> keys, gpg keys, etc) please see the firefox profile for examples.
>
OK, thanks! I'll update as suggested.

[Jamie Strandboge (jdstrand)]

This is milestoned for ubuntu-10.04-beta-1 -- what is the status for getting this in before then?

[Rick McBride (rmcbride)]

I have proposed the fix branch for merge. I'm awaiting review. I've addressed the needs-fixing item listed.

[Kees Cook (kees)]

Okay, unmilestoning, as we keep seeing changing behavior with the profile. This should be better tested and rolled out in M, instead.

[Jamie Strandboge (jdstrand)]

This is unfortunate. Could a disabled profile be shipped instead or at the very least an 'example profile' be shipped in /usr/share/doc? This way users can at least test and use the profile and give feedback along the way.

[Rick McBride (rmcbride)]

I'm investigating the best way of implementing Jamie's suggestion. It would be great to get user feedback on this.

[Jamie Strandboge (jdstrand)]

Rick, this is actually quite easy. Ship the profile as if it is enforcing, then put a symlink to it in /etc/apparmor.d/disable. Eg, if you install the profile to /etc/apparmor.d/usr.lib.ubuntuone-client.ubuntuone-syncdaemon, then do:
# ln -s /etc/apparmor.d/usr.lib.ubuntuone-client.ubuntuone-syncdaemon /etc/apparmor.d/disable/usr.lib.ubuntuone-client.ubuntuone-syncdaemon

You can see the firefox packaging for a (rather complicated) example. libapache2-mod-apparmor has a less complicated example I think.

[Rick McBride (rmcbride)]

I'm going to update the branch as described.

[Jamie Strandboge (jdstrand)]

Rick, curious on the status of the disabled profile. Will it make it into Lucid?

[Rick McBride (rmcbride)]

On 04/09/2010 10:59 AM, Jamie Strandboge wrote:
> Rick, curious on the status of the disabled profile. Will it make it
> into Lucid?
>
I had one failed attempt where I tried to handle it in debian/rules

I downloaded the source for the examples you referenced, but got side
tracked with operations stuff, and then was rather ill last night and
today. I'm hopeful that I can get this done either over the weekend or
on Monday. It shouldn't be that difficult, I simply haven't done this
exact sort of thing before.

[John Lenton (chipaca)]

ping :)

[Rick McBride (rmcbride)]

Yep, rotated back to operations+ and will get the needful resolved during or shortly after UDS.

Tried to reply via email but LP no longer recognizes my signature :/

[Rick McBride (rmcbride)]

at this point this is a next-cycle type activity.

[Jamie Strandboge (jdstrand)]

What is the status of this bug? If we are going to be shipping a disabled file instead of enforcing, we can mark as Wishlist/low instead.

[Rick McBride (rmcbride)]

Jamie,

My work was focused elsewhere this past cycle. I hope to revisit (or help someone else revisit) this in the future.