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

[Seth Arnold]

On Wed, May 31, 2017 at 02:33:46PM +0200, daniel curtis wrote:
> Thank You for an answers. I understood many things, thanks to You. I
> appreciate it, really.

Hi Daniel, thanks :) This is wonderful to hear.

> First thing; if it's about 'xdg-screensaver' issues etc.; You've written,
> that if I "don't trust data being supplied to Parole" then I should,
> probably, prefer/use the 'Px' rule instead of 'PUx', right? But after this
> change and use apparmor_parser(8) utility to load a "new" profile, log
> files contains;
> 
> audit: type=1400 audit(1496230982.227:68): apparmor="DENIED"
> operation="exec" info="profile transition not found" error=-13
> profile="/usr/bin/parole" name="/usr/bin/xdg-screensaver" pid=3304
> comm="sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
> target="/usr/bin/xdg-screensaver"
> 
> Returning to the "PUx" rule, seems to help - there is no DENIED entry etc.
> (NOTE: With "Px" rule, Parole works OK - just this log entry.) So, what
> should I do in this situation? I'm trusting data supplied to Parole. I hope
> so... :- ) And answering to your question; I did not notice, that Parole is
> downloading anything from the web; nor song lyrics, nor album art etc.

I'm sorry -- left unsaid with "Switch to Px" is also "write a profile for
xdg-screensaver". Hopefully it'll be short, probably just three or four
abstractions and five or six dbus rules if you want it tight or one dbus
rule if you don't mind it being looser.

> Now "orcexec.*" files; I decided to change rules and add 'deny' instead
> 'owner'. After reloading profile, Parole seems to work normally and there
> is not any DENIED entries in a log files. I did the same thing with a
> PulseAudio profile, because there are similar rules. No problems so far. I
> will do the same in a every profile with these rules and keep an eye on
> this issue.

Note the side-effect of this is perhaps higher CPU use than otherwise.

> I have asked about "aqueue:src", right? It was in a log entry related to
> the "orcexec.*" files:
> 
> 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
> 
> Can You write something more about this, now? I'm asking, because You've
> mentioned rootkits etc. Should I made some changes in profile e.g. with
> rules etc.? (You've written: "So be sure to use the /run/user/..." Is it
> enough? Just change "/{,var/}run/user/" to the "/run/user/..."? Geez, what
> a naive question. Sorry.)

This doesn't look like rootkit behaviour; it feels consistent with the
rest of the application.

We recently switched style from "/{,var/}run/user/" to "/run/user/" on the
theory that probably everyone with recent apparmor has also already made
the corresponding change to their filesystem.

Feel free to add

owner /run/user/*/orcexec.* rwm,

to this profile.

> Parole seems to work OK, even when a profile is in an "enforce" mode. I
> will do some more tests to exclude errors etc. Should I paste that Parole
> profile somewhere? Does it make any sense?
> Maybe this profile is not so bad and can be added to the AppArmor profiles?
> :- )

Yes, once you're happy with it we'd be happy to have it in the apparmor
profile collection!

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/20170531/ab5620f8/attachment.pgp>