[apparmor] [profile] Parole: a couple of questions.

Wed May 31 00:56:14 UTC 2017

On Sun, May 28, 2017 at 04:11:04PM +0200, daniel curtis wrote:
> Last year I've created an AppArmor profile for Parole application. However,
> it was done on the 12.04 LTS Release, which is in EoL status now. After
> fresh 16.04 LTS installation and checking log files for any new
> DENIED/ALLOWED entries (Parole was in a "complain" mode), I was surprised
> that there will be so many rules needed.

Hello Daniel; such is the software world, most programs keep gaining
features, toolkits gain features, etc. When programs stop changing rather
than call them 'finished' we tend to call them 'stale' or 'dead'.

When I started with Linux, the joke was "emacs" stood for "eight megabytes
and constantly swapping". You really could run a Linux machine on 4
megabytes of RAM but 16 megabytes or more was recommended for X11.
Everything keeps growing.

So it's not surprising that with four years newer software there are
some new features or new requirements.

> (Anyway, Parole is working okay; I can listen to an audio CD, change
> settings and so on.)

> (1) During testing, log files contained many entries related to the
> 'xdg-screensaver'. Here are two of them;

> /usr/bin/parole//null-/usr/bin/xdg-screensaver//null-/usr/bin/xprop
> 
> But after next system boot/start, above entries vanished. There was many
> more issues with this thing. I wondered how to solve this: create a child
> profile or a separate "xdg-screensaver" profile?

These temporary profiles are created when a process confined with a
profile in complain mode executes another program without already having
the corresponding 'x' rules in the profile. They persist until the
AppArmor utilities replace them, or you use the
/sys/kernel/security/apparmor/.remove interface, or use
apparmor_profile --remove (which uses the above interface) to remove them
if you choose to generate profiles by hand with complain mode. (I'm
actually not too positive about this, since I don't think we currently
have renaming-replace support in the kernel. Anyway, it's not surprising
they go away when you reboot.)

> And at last I used this rule, which seems to solve all these issues with
> "xdg-screensaver", but I don't know if this rule is secure etc.:
> 
> /usr/bin/xdg-screensaver PUx,
> 
> What do you think abouth this rules? Is it okay and can be used in a Parole
> profile?

PUx may make more sense for distribution-supplied profiles -- you, the end
user, generating a profile, can decide for youself if you want
xdg-screensaver to be confined or unconfined. PUx makes it easy to change
your mind in the future, of course, but normally you would have a stronger
opinion.

If you don't trust data being supplied to Parole then you should probably
prefer the Px choice. (Does it download lyrics or song names or album art
over the internet?)

> (2) Next thing, that showed up during testing is:
> 
> ✗ May 27 17:29:27 t1aa-test kernel: [ 9102.161080] audit: type=1400
> audit(1495898967.296:70): apparmor="DENIED" operation="connect"
> profile="/usr/bin/parole" pid=3181 comm="parole" family="unix"
> sock_type="stream" protocol=0 requested_mask="send receive connect"
> denied_mask="send connect" addr=none
> peer_addr="@/dbus-vfs-daemon/socket-dYRYyAQi" peer="unconfined"
> 
> I have had many problems with this entry, because I have no idea, which
> rule I should use. And I decided to use this one:
> 
> unix (connect, receive, send) type=stream
> peer=(addr="@/dbus-vfs-daemon/socket-*"),
> 
> Again: what do you think about this rule? Can it be used in a profile? Is
> it secure enough? I remind, that Parole works normally.

If it works 'normally' while this is denied, that simply means you don't
use whatever service is provided by the process listening to the listed
socket. :)

On my computer there's several processes using such sockets; I don't knof
off-hand which ones might be listening vs using these sockets:

- gvfsd-trash
- gvfsd-burn
- gvfsd-dnssd

I don't know what any of these programs do. I can guess but that's just me
guessing. You'll have to figure out what application specifically Parole
is trying to contact and if you want to allow that communication. Probably
a file open or file save dialog box of some sort is involved.

> (3) Now an 'abstractions' issue. It's better to use 'abstractions' or I
> should create the right rule? At some moment, log files started to include
> something like this one: "addr=none peer_addr="@/tmp/.X11-unix/X0"
> denied_mask="send connect" and so on.
> 
> Similar rules can be found in <abstractions/X>. So, what should I do: use
> 'abstractions' or only rules? These rules are:
> 
> /tmp/.X11-unix/*           w,
> unix (connect, receive, send)
> type=stream
> peer=(addr="@/tmp/.X11-unix/X[0-9]*"),
> unix (connect, receive, send)
> type=stream
> peer=(addr="@/tmp/.ICE-unix/[0-9]*"),
> 
> For now, I'm using <abstractions/X> but I would like to ask what is the
> better solution in this case? What is your opinion on this one?

This is difficult to know exactly. In general any graphical program may
use most of the resources in <abstractions/X> so it makes good sense to
include it. Since most GUI apps these days are gnome apps or kde apps it
probably makes more sense to include <abstractions/gnome> or
<abstractions/kde>, which in turn includes <abstractions/X>.

> (4) Log entries related to the dbus. There is an log entry to which I have
> had to create a rule. A log entry looks this way:
> 
> ✗ May 27 18:25:42 t1aa-test kernel: [12477.582553] audit: type=1107
> audit(1495902342.717:109): pid=1023 uid=106 auid=4294967295 ses=4294967295
> msg='apparmor="DENIED" operation="dbus_method_call"  bus="system"
> path="/org/freedesktop/hostname1"
> interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send"
> name=":1.113" pid=3670 label="/usr/bin/parole" peer_pid=3678
> peer_label="unconfined"
> 
> And a rule (please note path= entry; it contains "hostname1".) Is it okay
> to use something like this one?
> 
> dbus send
>      bus=accessibility
>      path=/org/freedesktop/hostname1
>      interface=org.freedesktop.DBus.Properties
>      member=GetAll,

Note that the log says bus="system"; this rule specifies bus=accessbility,
so it would not actually satisfy this log message.

I can't make heads or tails of
https://people.freedesktop.org/~david/xdg-hostname/Hostname1.html -- at
least this looks like the documentation for the service in question --
but it kind of looks like a way for applications to get the hostname? It's
probably fine to allow it.

> (5) At some point, there appeared a log entries, which can be found in the
> <abstractions/audio> file. And a question arises: it's better to use an
> 'abstractions' or a rules? For now, I'm using a rules, because I don't need
> everything from an 'audio' abstractions etc.
> 
> Needed rules concern e.g.: '/etc/pulse/' folder, '/{run,dev}/shm/' or
> '/etc/openal/alsoft.conf' file. So, what should I do?

I'd definitely use the audio abstraction if you're using an application
that does audio things :)

> (6) There was a problem with a Gstreamer module error after insterting an
> audio CD disc etc. Everything start to work after adding this rule to the
> Parole profile:
> 
> unix peer=(addr=@/tmp/.ICE-unix/* label=unconfined),
> 
> Gstreamer doesn't work without this, right? So I think, that this rule is
> okay and should be leave. Am I right?

Probably; once you include an X abstraction or gnome abstraction or kde
abstraction (as appropriate) this will probably already be handled.

> (7) There was also issues with an "orcexec.*". Because I have /tmp
> partition mounted with a "noexec" option, I have had to add a couple of
> rules. Log entry and rules:
> 
> ✗ May 28 11:20:24 t1aa-test kernel: [ 3238.285728] audit: type=1400
> audit(1495963224.908:82): apparmor="DENIED" operation="mknod"
> profile="/usr/bin/parole" name="/run/user/1000/orcexec.IveM1L" pid=3649
> comm="aqueue:src" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> 
> The rest of this log entry contains; "/home/user1/orcexec.iiRYBl" and
> "/tmp/orcexec.yeFccV". Added rules:
> 
> owner /tmp/orcexec.* mrw,
> owner /{,var/}run/user/[0-9]*/orcexec.* mrw,
> owner @{HOME}/orcexec.* mrw,
> 
> Are they okay? Can I leave them in a Parole profile?

These are troubling. Based on https://askubuntu.com/a/338118/33812 these
files look like on-demand self-modifying code. While it's possible to use
/tmp/ for this safely I'd be very surprised if this _is_ safe. So be sure
to use the /run/user/... or @{HOME} variants, to prevent cross-user
attacks. Hopefully it only uses /tmp/ as a fall-back if the others fail.

> Okay; that's all for now. By the way; why there is no Parole in the
> '/etc/apparmor.d/abstractions/ubuntu-media-players' file? There is e.g.
> Totem and VLC but no Parole. Is there any reason for such situation?

Because you haven't submitted the profile yet :)

More seriously, this is the first I've heard of Parole. There's dozens of
tools like this, so it's not a surprise that we're missing some.

> I have one more question; what means something like this one:
> comm="aqueue:src". It was in one of the log entry, but I don't remember
> where. Is it something bad or normall?

This one is again a gray area; it's easy enough for a program to change
its comm field to provide status reports via top or ps output:
http://sources.debian.net/src/dictd/1.12.1%2Bdfsg-4/dictd.c/#L1757
But sometimes rootkits will mask their processes with this.

Without knowing more about whatever program this is it's hard to say if it
is legitimate or not.

> Please forgive me; I'm sorry for such a long message. It seems, that Parole
> is working in an 'enforce' mode. I can paste this profile somewhere and
> someone of you could check if it's secure profile to use etc. Once again:
> I'm sorry.

We're happy to help; don't be sorry for being curious. :)

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20170530/2f3d1660/attachment.pgp>