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
signature.asc
Description: PGP signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
