Apparmor profiles: ambiguous syntax error (?) on aa-complain

[ermor]

Hello everyone,

I'm currently trying to set up Apparmor on my install, and I've stumbled upon this up-to-date repository of extra profiles. Only problem with it, as far as I can see, is that it's based on the upstream version of Apparmor, and the Gentoo version is a little bit behind. I've been manually picking profiles and the required abstractions/tunables and trying to edit them so that they work with Gentoo Apparmor (as far as I can tell). So far, all I really did was decreasing the abi from 4.0 to 3.0, removing all mentions of the @{exec_path} variable in each profile (apparently leaving them in causes issues upon loading the profiles because the parser seems to think the same variable is being redefined several times), and changing the value of the @{bin} abstraction to be the same as @{sbin}, since they're both essentially the same on Gentoo. I've done it for a few profiles now, it seems to be working alright.

But I have a bit of an issue with the profile for man. When I try to set it to Complain Mode, I get this output :

Code: Select all

aa-complain man
Setting /usr/bin/man to complain mode.

ERROR: /etc/apparmor.d/usr.bin.man doesn't contain a valid profile for /usr/bin/man (syntax error?)

It's not the first time I get that kind of error from Apparmor, I wish it was more helpful. I know it can be caused by complaining the wrong executable, I think, and not having the right permissions on the profile or the required files. I don't think the executable I specified is at fault, "which man" suggests it's the correct one. I double checked, and all required files (the man profile itself, plus the child-pager profile and the /abstraction/app/pager file) are there, and all world-readable. Same for the required "tunables" variables, they're all there and the required files are world-readable, but I remember Apparmor telling me when a variable definition was missing in the past so I don't think that's the issue. All the directories I have created while setting up the required files (like the /abstraction/app/ directory) also have the right permissions: r-x on everyone but the owner, which has rwx.

I've done a lot of research on the subject, but I didn't come up with much. The closest I could find was this thread, but I don't think this is my issue. I've tried these commands:

Code: Select all

aa-complain man
aa-complain /usr/bin/man
aa-complain /usr/sbin/man
aa-complain usr.bin.man

The first three output the error. Curiously, the last one doesn't, and it tells me it's setting the profile itself (as in, the /etc/apparmor.d/usr.bin.man file) to complain mode, but when I reboot, man completely breaks instead of complaining. aa-status also tells me the profile for man is in complain mode, but not the process itself. For my more successful attempts, aa-status does tell me the related processes are in complain/enforce mode. I'm not completely sure what the difference is between the two wordings.

Does anyone knowledgeable with Apparmor can help me figure out what's wrong?

[pietinger]

[...] The first three output the error. Curiously, the last one doesn't, and it tells me it's setting the profile itself (as in, the /etc/apparmor.d/usr.bin.man file) to complain mode, but when I reboot [...]

If you want to set a profile permanent to complain mode - even after a reboot - you should add it in the profile; e.g.:

Code: Select all

/usr/bin/man flags=(complain)

Maybe show us the first 12 lines of your /etc/apparmor.d/usr.bin.man and the output of ls -al /

[pietinger]

P.S.: See also: https://gitlab.com/apparmor/apparmor/-/ ... e#profiles

[ermor]

Hello Pietinger,

Here are the first few lines of the file, and the output of the ls command. Save for the complain flags being added, my changes are contained in the uploaded bit. I commented out four lines (5, 10, 11 and 19) and replaced them with my changes.

If you want to set a profile permanent to complain mode - even after a reboot - you should add it in the profile

Apparently aa-complain does it on its own, I noticed the flags being applied to all three profiles defined in the file, even though they weren't in the original download and I didn't add them in myself.

P.S.: See also: https://gitlab.com/apparmor/apparmor/-/ ... e#profiles

Thanks for the link. The name and attachment were already set in the download, and I tried both when I attempted to complain the profile/process, to no avail. They look correct to me, not sure what's wrong with this profile.

EDIT: The Vim syntax highlighter for Apparmor seems to highlight the various "signal peer=" lines in red. The manpage for the plugin doesn't give a color code, and I haven't found one yet, but I suppose this could mean they're not intertpreted correctly by the parser. I'll try commenting them out to see if it works better.

EDIT: No, it doesn't seem to make a difference.

[pietinger]

[...] I noticed the flags being applied to all three profiles defined in the file, even though they weren't in the original download and I didn't add them in myself.

Which THREE files do you mean?

Hmm ... when I look into https://github.com/roddhjav/apparmor.d/ ... d/tunables I dont see a "global" file. So, I guess it was installed during some special install commands? It would be interesting to see how @{bin} was defined. Also: What is logged in "dmesg"?

I would like to point out that I have no knowledge of AA Version 4 ... so I don't think I can be of much help to you. We probably need a real expert on AA who knows the differences between versions 3 and 4.

Internal note (because pastebin service delete files after a while):

Code: Select all

# abi <abi/4.0>,
abi <abi/3.0>,

include <tunables/global>

# @{exec_path} = @{bin}/man
# profile man @{exec_path} {
profile man @{bin}/man flags=(complain) {
  include <abstractions/base>
  include <abstractions/consoles>

  signal peer=man//man_groff,
  signal peer=man//man_filter,

#  @{exec_path} mr,
  @{bin}/man mr,

  # Use a special profile when man calls anything groff-related. We only include
  # the programs that actually parse input data in a non-trivial way, not
  # wrappers such as groff and nroff, since they would need a broader profile.
  @{bin}/eqn      rCx -> man_groff,
  @{bin}/grap     rCx -> man_groff,

I also use AA myself, but I wrote all my profiles myself (because, for example, I don't allow the browser to read my /home directory). I have only created profiles for "dangerous" programs. This is what it looks like for me:

Code: Select all

# aa-status 
apparmor module is loaded.
17 profiles are loaded.
17 profiles are in enforce mode.
   chronyd
   falkon
   gwenview
   konqueror
   kontact
   konversation
   marble
   mupdf-gl
   okular
   ping
   privoxy
   tokodon
   traceroute
   unbound
   vlc
   wesnoth
   wget
0 profiles are in complain mode.
0 profiles are in prompt mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
21 processes have profiles defined.
21 processes are in enforce mode.
   /usr/bin/chronyd (2074) chronyd
   /usr/bin/falkon (4764) falkon
   /usr/lib64/qt6/libexec/QtWebEngineProcess (4776) falkon
   /usr/lib64/qt6/libexec/QtWebEngineProcess (4777) falkon
   /usr/lib64/qt6/libexec/QtWebEngineProcess (4834) falkon
   /usr/bin/konqueror (3434) konqueror
   /usr/lib64/qt6/libexec/QtWebEngineProcess (3471) konqueror
   /usr/lib64/qt6/libexec/QtWebEngineProcess (3472) konqueror
   /usr/lib64/qt6/libexec/QtWebEngineProcess (3613) konqueror
   /usr/lib64/qt6/libexec/QtWebEngineProcess (3835) konqueror
   /usr/libexec/kf6/kioworker (4655) konqueror
   /usr/bin/kontact (2888) kontact
   /usr/lib64/qt6/libexec/QtWebEngineProcess (2902) kontact
   /usr/lib64/qt6/libexec/QtWebEngineProcess (2903) kontact
   /usr/lib64/qt6/libexec/QtWebEngineProcess (2950) kontact
   /usr/lib64/qt6/libexec/QtWebEngineProcess (2979) kontact
   /usr/lib64/qt6/libexec/QtWebEngineProcess (3083) kontact
   /usr/bin/konversation (3342) konversation
   /usr/bin/privoxy (2008) privoxy
   /usr/bin/tokodon (3296) tokodon
   /usr/bin/unbound (2018) unbound
0 processes are in complain mode.
0 processes are in prompt mode.
0 processes are in kill mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.

[ermor]

Which THREE files do you mean?

Sorry, I wasn't very clear. The man profile uses three other "subprofiles": man_groff, man_filter and child-pager. The first two are defined in the main man file alongside the man profile itself, but the last one has its own file. The online repository puts it in groups/children, but I put it in apparmor.d with the other profiles.

Hmm ... when I look into https://github.com/roddhjav/apparmor.d/ ... d/tunables I dont see a "global" file. So, I guess it was installed during some special install commands? It would be interesting to see how @{bin} was defined.

This file isn't part of the online repository, it's from sec-policy/apparmor-profiles, if I'm not mistaken. It's used to include most of the content of tunables. The alias, home, multiarch and xdg-user-dirs are included, so I don't think anything important is missing. Now that I'm looking at it, though, the alias file doesn't include its equivalent directory, like the other files do. I don't think this causes my issue, the content of alias.d doesn't seem related to the man profile, but maybe I should look into it. As for @{bin}, it's defined in tunables/multiarch.d/system. Its original content was "/{,usr/}bin", but I put "/{,usr/}{,s}bin" instead to be exhaustive, since it all points to the same thing in Gentoo.

Also: What is logged in "dmesg"?

Not much related to Apparmor, it seems. A few profile loads and an ALLOWED operation for auditd.

[pietinger]

[...] As for @{bin}, it's defined in tunables/multiarch.d/system. Its original content was "/{,usr/}bin", but I put "/{,usr/}{,s}bin" instead to be exhaustive, since it all points to the same thing in Gentoo.

Hmm ... I dont would do this ... @{bin}=/usr/bin ... and @{sbin}=/usr/sbin ... because you have already a merged-usr profile (the reason I asked for ls / was to see if you have an old split-usr or a current merged-usr profile active). The more you work with concrete directories (and files) the fewer security-related permissions exist. (You surely already know that you must include files where variables are defined before you can use them.)

When I searched for errors in my profiles I stripped it down to the header (and one rule) and inserted all values of variables directly into the profile. Then I added one rule after next rule. It was almost a missing comma or one comma too much ...

P.S.: You will work with: apparmor_parser -r usr.bin.man

[ermor]

[...] As for @{bin}, it's defined in tunables/multiarch.d/system. Its original content was "/{,usr/}bin", but I put "/{,usr/}{,s}bin" instead to be exhaustive, since it all points to the same thing in Gentoo.

Hmm ... I dont would do this ... @{bin}=/usr/bin ... and @{sbin}=/usr/sbin ... because you have already a merged-usr profile (the reason I asked for ls / was to see if you have an old split-usr or a current merged-usr profile active). The more you work with concrete directories (and files) the fewer security-related permissions exist. (You surely already know that you must include files where variables are defined before you can use them.)

Alright, I set it back to the original value. I suppose I don't really need another definition than /usr/bin/ anyway.

When I searched for errors in my profiles I stripped it down to the header (and one rule) and inserted all values of variables directly into the profile. Then I added one rule after next rule. It was almost a missing comma or one comma too much ...

That's what I ended up doing, and the error is apparently caused by the use of the @{bin} variable in the attachment. I'm quite baffled by that, never had any issue before when doing it that way, but sure enough, trying to complain auditd again failed with the same mysterious error. Not sure what changed.
That said, man is still being blocked, even though the profile is set to Complain and I allowed everything related with aa-logprof. I've seen a comment by the repository author saying that the abi 3.0 was deprecated and no longer supported, so I'm starting to think it's no use trying to be too thorough with what little understanding I have of Apparmor and the processes I'm trying to confine. I should probably just confine the really important stuff, and do it manually too.
How do you determine what's dangerous? I'm assuming it's anything network-related, but just to be sure. I've seen others say that it would be anything that listens to network ports, is executed as root and is frequently used. Do you contain the processes in the output of aa-unconfined, or are there other considerations? And how exactly do you know if a rule is actually needed for a process you don't necessarily know and understand? A lot of processes seem to want me to give them "capability sys_admin", but I don't see why they'd need it.

P.S.: You will work with: apparmor_parser -r usr.bin.man

I was wondering about this command. I've seen it a few times when looking at tutorials and articles, but I've also NOT seen it on others, and I never used it before you suggested it. aa-complain seemed to work. Does it resets the profile in the kernel without having to reboot the system? I usually reboot after I modify anything.

[pietinger]

That's what I ended up doing, and the error is apparently caused by the use of the @{bin} variable in the attachment. I'm quite baffled by that, never had any issue before when doing it that way, but sure enough, trying to complain auditd again failed with the same mysterious error. Not sure what changed.
That said, man is still being blocked, even though the profile is set to Complain and I allowed everything related with aa-logprof. I've seen a comment by the repository author saying that the abi 3.0 was deprecated and no longer supported, so I'm starting to think it's no use trying to be too thorough with what little understanding I have of Apparmor and the processes I'm trying to confine.

I am working without an abi file (-> abi <kernel>,) ... Do you know what abi does? If not:

You can define what AA will check. And then AA will ONLY check these and nothing else ... even ... if the kernel would be capable to do so. Why is this used? Because sometimes the kernel has a new capability. I can remember the introduction of the capability CAP_CHECKPOINT_RESTORE (since 5.9; see also "man capabilities"). Now, what would happen if a programm needs this ... and the AA-kernel-module is able to check it ... BUT there is no rule in the profile. Yes the programm would not get the permission with this "old" profile. The solution would be:

1. to add it in the profile ... OR
2. what all distributions want: If it is not defined in the abi-definition, THEN the AA-kernel-module will not check it, and so you can use the "old" profiles even when there are new options/checks available.

And this is exactly what I dont want. If there is a new option/check available I WANT to know about, even this means I must update my profile(s). I define as abi the kernel and THEN it is only important what the AA-kernel-module is able to proof.

(See also here: https://gitlab.com/apparmor/apparmor/-/ ... eaturesabi and the next pages)

You can see what the kernel can do with:

Code: Select all

ls -R /sys/kernel/security/apparmor/features/

How do you determine what's dangerous? I'm assuming it's anything network-related, but just to be sure. I've seen others say that it would be anything that listens to network ports, is executed as root and is frequently used. Do you contain the processes in the output of aa-unconfined, or are there other considerations?

Yes, aa-unconfined tell you the minimum. But ... all programms which process external data can be dangerous ... and sometimes they are. I had read about security problems in vlc (processing video data==dangerous data), okular (process PDF data==dangerous data) ... AND ... of course all browsers.

I make a rough distinction between programs that have/need network access and local programs. Programs with network access have very limited access to local file systems (and of course not to my /home); the others are allowed to do quite a lot locally, but have no way of establishing a network connection. Yes, there are programs that want both... but my browser doesn't crash when I want to download a file, it just reports that it doesn't have access to my home directory. Yes, it is only allowed to read and write in ~/Downloads (and of course its own configuration files). Gwenview is simply not allowed to access the Internet. I don't care if a program complains that there is no network. I simply won't allow it. Yes, it is a common misconception that you have to allow a program to do everything it can/wants to do. No, a proper program does not crash if there is no Internet/network. (Of course, I have created all profiles in a slightly more granular way).

Maybe look into:
https://forums.gentoo.org/viewtopic-t-1124305.html
and to see what "include <local/ONLYNETWORK>" does, look into
https://forums.gentoo.org/viewtopic-t-1124308.html
(ONLYLOCAL is the opposite of ONLYNETWORK and is included by all local programs; yes, you can only include one of these both; a list of my posts is in this post: https://forums.gentoo.org/viewtopic-p-8 ... ml#8537506)

And how exactly do you know if a rule is actually needed for a process you don't necessarily know and understand? A lot of processes seem to want me to give them "capability sys_admin", but I don't see why they'd need it.

CAP_SYS_ADMIN is really bad (because it is overloaded) ... please see again "man capabilities" ... yes, some applications really need it ... try to use other programms instead.

P.S.: You will work with: apparmor_parser -r usr.bin.man

I was wondering about this command. I've seen it a few times when looking at tutorials and articles, but I've also NOT seen it on others, and I never used it before you suggested it. aa-complain seemed to work. Does it resets the profile in the kernel without having to reboot the system? I usually reboot after I modify anything.

Oh no. Please do not reboot. Yes, apparmor_parser -r (long: --replace) does exactly what you think: You exchange the current profile of an application with a new/modified/updated profile (with the same name) you give to the kernel. See also: "man apparmor_parser". It is the most important application when testing/checking a profile.

[pietinger]

I forgot to mention something: Before you try to protect some dangerous programs with AA, you should have a Personal FireWall installed/active. Why? Because then you can immediately see which programs are communicating with the evil Internet... because you have to allow them in your firewall. Yes, you should definitely have a web proxy through which all traffic from port 443 (and 80) runs. Then you can see who is communicating in the log of your web proxy. You should definitely give these applications an AA profile... and all programs that have already been noticed for security vulnerabilities in the past. You may also be interested in this wiki article: https://wiki.gentoo.org/wiki/User:Pieti ... x_FireWall

(You can now see my complete configuration through my output of aa-status and my FW rules:
- NTP is done by “chronyd” (only to certain servers)
- DNS over TLS is done by the caching DNS resolver “unbound” (only to certain servers)
- All HTTPS communication runs via “privoxy”
- Mail (via POP3S and SMTP) only to my mail provider servers (kontact from KDE)
- IRC only to Libera servers (konversation from KDE)
- Mastodon via the web proxy "privoxy" (tokodon from KDE)

[ermor]

I am working without an abi file (-> abi <kernel>,) ... Do you know what abi does? If not:

You can define what AA will check. And then AA will ONLY check these and nothing else ... even ... if the kernel would be capable to do so. Why is this used? Because sometimes the kernel has a new capability. I can remember the introduction of the capability CAP_CHECKPOINT_RESTORE (since 5.9; see also "man capabilities"). Now, what would happen if a programm needs this ... and the AA-kernel-module is able to check it ... BUT there is no rule in the profile. Yes the programm would not get the permission with this "old" profile. The solution would be:

1. to add it in the profile ... OR
2. what all distributions want: If it is not defined in the abi-definition, THEN the AA-kernel-module will not check it, and so you can use the "old" profiles even when there are new options/checks available.

And this is exactly what I dont want. If there is a new option/check available I WANT to know about, even this means I must update my profile(s). I define as abi the kernel and THEN it is only important what the AA-kernel-module is able to proof.

Thanks for the explanation! You're right, I'd rather edit the profile if necessary. I set "abi <kernel>" in my new profile.

Yes, aa-unconfined tell you the minimum. But ... all programms which process external data can be dangerous ... and sometimes they are. I had read about security problems in vlc (processing video data==dangerous data), okular (process PDF data==dangerous data) ... AND ... of course all browsers.

I make a rough distinction between programs that have/need network access and local programs. Programs with network access have very limited access to local file systems (and of course not to my /home); the others are allowed to do quite a lot locally, but have no way of establishing a network connection. Yes, there are programs that want both... but my browser doesn't crash when I want to download a file, it just reports that it doesn't have access to my home directory. Yes, it is only allowed to read and write in ~/Downloads (and of course its own configuration files). Gwenview is simply not allowed to access the Internet. I don't care if a program complains that there is no network. I simply won't allow it. Yes, it is a common misconception that you have to allow a program to do everything it can/wants to do. No, a proper program does not crash if there is no Internet/network. (Of course, I have created all profiles in a slightly more granular way).

Maybe look into:
viewtopic-t-1124305.html
and to see what "include <local/ONLYNETWORK>" does, look into
viewtopic-t-1124308.html
(ONLYLOCAL is the opposite of ONLYNETWORK and is included by all local programs; yes, you can only include one of these both; a list of my posts is in this post: viewtopic-p-8537506.html#8537506)

I'll have a look, thanks! I don't have much with network access right now, but I'll keep the info in mind for later.

CAP_SYS_ADMIN is really bad (because it is overloaded) ... please see again "man capabilities" ... yes, some applications really need it ... try to use other programms instead.

Yeah, I stumbled upon "man capabilities" a few days ago and saw CAP_SYS_ADMIN was... a bit much. Truth be told, when I said "a lot of programs" wanted it, I really meant dhcpcd and man. I can conceive dhcpcd would have a use for it, but I don't really see why man would care. I denied it, see if anything happens on the long run.

Oh no. Please do not reboot. Yes, apparmor_parser -r (long: --replace) does exactly what you think: You exchange the current profile of an application with a new/modified/updated profile (with the same name) you give to the kernel. See also: "man apparmor_parser". It is the most important application when testing/checking a profile.

Thanks for the tip, works great. Makes testing a bit quicker.

I forgot to mention something: Before you try to protect some dangerous programs with AA, you should have a Personal FireWall installed/active.

I set one up a few months ago, I think it was NeddySeagoon who recommended it to me. Since I don't have much communicating with the network, I'm blocking most things for now. Thanks again for the link, I'll check it out too!

So I remade a profile from scratch for man. I don't think it's too much of a threat to confine, but it's a nice exercise, and it's easy enough to check if it works. So far so good, it's smaller than the other one and I can actually browse man pages, though I set all the required execute rules to Inherit, which I suppose is only a temporary measure. I guess I should build a profile for these processes too. I'd only have to execute them myself and check with aa-logprof, right? Curiously, I tried making them local Child profiles at first, but the sub-profiles remained empty and apparmor_parser kept complaining about them (merged rules with conflicting x modifiers). I assumed aa-logprof would fill them out like it did with the man profile, but that's apparently not the case.

For future reference, if anyone else is having troubles with Apparmor, the OpenSuse documentation has a nice section on the subject.

[pietinger]

So far so good, it's smaller than the other one and I can actually browse man pages, though I set all the required execute rules to Inherit, which I suppose is only a temporary measure. I guess I should build a profile for these processes too. I'd only have to execute them myself and check with aa-logprof, right? Curiously, I tried making them local Child profiles at first, but the sub-profiles remained empty and apparmor_parser kept complaining about them (merged rules with conflicting x modifiers). I assumed aa-logprof would fill them out like it did with the man profile, but that's apparently not the case.

Hmm ... I work only with ix. I dont would say this is only a temporary measure (but maybe I am ignorant here because I have only 17 profiles in use ). Sorry, I cannot help with aa-logprof because I never used it. I used complain-mode and dmesg to see what a programm needs and made everything by hand => After I made some profiles (dont know ... maybe 5 or 6) I looked for same rules ... and moved them into an extra file (which I can include) ... and ... of course I inspected the profiles from our AA-profiles-package, especially the "base" and some other. And because I dont like to have too many files in etc/apparmor.d/local I merged some of them; e.g. the tmp-rules I copied into (my) BASE.

For future reference, if anyone else is having troubles with Apparmor, the OpenSuse documentation has a nice section on the subject.

Thank your very much for this PDF. I have read the AA chapter and have two remarks:

1. They say you can use #include or include. But #include is deprecated; use only: include (without #)

2. Dont try to write a profile for /usr/bin/sshd ... You should protect your sshd with a firewall (e.g., only allow access from an admin station; companies have their own subnet/VLAN containing all admin workstations that are allowed to access the servers via ssh). If you really want to access a server via ssh over the Internet, only do so via a VPN connection. Never allow a ssh-connection from the internet. Yes, I know there exists fail2ban ... I dont suggest ... too dangerous ... just never allow access from the internet ... only from a VPN.

[ermor]

Hmm ... I work only with ix. I dont would say this is only a temporary measure (but maybe I am ignorant here because I have only 17 profiles in use ).

It's just that I was thinking it could result in more permissions than necessary given to the newly executed program. Then again, it makes sense they'd need the same kind of access as the parent profile to work. Seems to work fine for now, though.

For future reference, if anyone else is having troubles with Apparmor, the OpenSuse documentation has a nice section on the subject.

Thank your very much for this PDF. I have read the AA chapter and have two remarks:

1. They say you can use #include or include. But #include is deprecated; use only: include (without #)

2. Dont try to write a profile for /usr/bin/sshd ... You should protect your sshd with a firewall (e.g., only allow access from an admin station; companies have their own subnet/VLAN containing all admin workstations that are allowed to access the servers via ssh). If you really want to access a server via ssh over the Internet, only do so via a VPN connection. Never allow a ssh-connection from the internet. Yes, I know there exists fail2ban ... I dont suggest ... too dangerous ... just never allow access from the internet ... only from a VPN.

You're welcome! And thanks for the tips. My firewall should be blocking ssh by default.

[pietinger]

[...] (process PDF data==dangerous data) [...]

From yesterday:
https://www.varonis.com/blog/matrixpdf

[ermor]

[...] (process PDF data==dangerous data) [...]

From yesterday:
https://www.varonis.com/blog/matrixpdf

I was looking at MuPDF's USE words a few days ago and was thinking to myself that JavaScript support seemed like a security risk for probably not that much gain. Seems like I was right.

Do you allow read access for .pdf in your entire home directory for Okular? You probably just turn off network access for it, right?

[pietinger]

Do you allow read access for .pdf in your entire home directory for Okular? You probably just turn off network access for it, right?

Okular can read only *.pdf. Yes, no network access.
->

Code: Select all

# cat local/VARIABLES 
# version 1

@{MYDATADIRS}=/home/*/ /mnt/ /media/ /hd/


# cat usr.bin.okular 
# version 1

abi <kernel>,

include <local/VARIABLES>
@{SFX}=pdf PDF

profile okular /usr/bin/okular
{
include <local/ONLYLOCAL>
include <local/ISAKDE>
# include <local/USECUPS>

owner /home/*/.local/share/okular/**  rw,
owner /home/*/.local/share/okular/bookmarks* l -> /home/*/.local/share/okular/#[0-9]*,

@{MYDATADIRS}/**.@{SFX}  rw,
}