Skype doesn't fully work in enforce mode

This file only has Skype's output to kern.log.

There's really two issues here; first is the new permissions Skype is requesting. I can't see why Skype would care about init's command line, so I think I'd just add a 'deny' rule for it to quiet the messages. Or leave it alone, if you'd rather be reminded that Skype is doing funny things. The other permissions it is requesting could be handled like this:

deny /proc/1/cmdline r,
owner /proc/*/status r,
/proc/modules r,
/sys/devices/*/*/usb*/*/* r,

/usr/share/icons/gnome/index.theme k,
/usr/share/icons/hicolor/index.theme k,

owner @{HOME}/.config/Skype/Skype.conf rw,

I've guessed at a very broad /sys/devices/*/*/usb*/*/* r, line, on the assumption that Skype should legitimately be able to query information about every USB device on the system. This might not be perfect, but will allow it to discover usual webcams and the like.

I don't know why Skype wants to lock the icon themes but on its own it feels harmless. If an update operation is hung due to Skype not releasing the lock in a timely fashion, an admin can always just kill Skype and be done with it.

Perhaps the above lines should be added to the default Skype profile. I'd like your feedback on what else might be needed once these lines are added.

The second issue is your changed location. The following lines will address your very specific error messages and allow you to use "~/New Folder/" as a download location:

@{HOMEDIRS} r,
@{HOME} r,
"@{HOME}/New Folder/" r,
"@{HOME}/New Folder/**" rw,

If you want the file browser to generally work everywhere, you'll probably want to add a line like:

@{HOME}/**/ r,

Of course, this still denies actually writing to nearly everything. If you _really_ want to allow downloading anywhere in a home directory, you could add something like:

#include <abstractions/private-files-strict>

@{HOME}/** rw,

Be aware that this is extremely permissive.

Thanks

Thank you for your quick reply. I added your suggested lines to Skype's profile. After reloading it, the only message that appears to kern.log is the error below. It should be noted that my webcam is an internal one but I guess Skype still wants to search for external webcams.

type=1400 audit(1371504139.242:295): apparmor="DENIED" operation="file_lock" parent=1 profile="/usr/bin/skype" name="/home/asentaja/.config/Skype/Skype.conf" pid=16177 comm="skype" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000

The error message appears twice in the log, the first time occurs at the beginning of a call and the second one at its end. I noticed that it disappears with the following rule (though I’m not sure what exactly the k parameter does):

owner @{HOME}/.config/Skype/Skype.conf krw,

Apart from the above errors, log in/out, calling and video all work well. However, I noticed that clicking on the credit balance button and then any of the purchase/account links leads to the following error:

type=1400 audit(1371506546.785:308): apparmor="DENIED" operation="exec" parent=16740 profile="/usr/bin/skype" name="/usr/bin/gvfs-open" pid=16741 comm="xdg-open" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Can you advice me what rule could fix it?

As for the file browser, I realise the security issue for allowing full access to the home folder and understand that there has to be a compromise between usability and security. Since the root of the home folder is not really the best place for downloaded files, and an empty directory listing is a bit confusing, would it be possible to add an access to at least the ~Downloads folder to the default profile?

I tried to add the rules below to the profile but reloading the profile complained about an undeclared XDG_DOWNLOAD variable. Could you please confirm whether AppArmor should work with that variable or should I open a new bug to get support for it?

@{XDG_DOWNLOAD} r,
"@{XDG_DOWNLOAD}/**" rw,

I am completely new to writing AppArmor profiles so I might just be doing something wrong with the above rules. Thanks.

'k' just allows the use of fcntl(2)-based advisory file locking. Allowing the program to lock its own configuration file is almost certainly harmless.

The xdg-open command is significantly harder to deal with -- it is probably using that to spawn a web browser, via a tool designed to make it easier to have any number of tools providing services for a given request.

I don't know what would be best here -- on the one hand, you want to allow Skype to eventually start a browser, but you'd like it to be safe.

We'll need to discuss how to handle this, and the XDG download directory, on the apparmor mail list, because I'm unfamiliar enough with xdg-open to know the best course of action.

If you mostly trust Skype, you can add /usr/bin/gvfs-open Ux. If you mostly distrust Skype, you should probably create a child profile for xdg-open (/usr/bin/xdg-open cx -> xdg_open, then add a new block to the profile, nested within, "profile xdg_open { /usr/bin/xdg-open ix, /usr/bin/firefox Px, .... }". It might take some experimentation to find the best balance of convenience versus safety for this case.

[Expired for apparmor (Ubuntu) because there has been no activity for 60 days.]

Just to add that there is some discussion about an AppArmor profile for Skype in bug 1325131. Thanks.