Allow rules to express paths using globbing (fnmatch)

[skosachiov]

The second implementation of fnmatch support, which works with trusted base. Briefly:

• all paths from rules with "*?" fill the wildcards llist
• the llist is sorted by bubble
• the comparison function during sorting is the difference in greed of wildcards
• the operations of filling the base and processing events with wildcard /home/*/.wine/* change the path from /home/jdoe/.wine/drive_c/windows/notepad.exe to /home/*/.wine/drive_c/windows/notepad.exe
• the operations of processing rules change the path from /home/jdoe/.wine/drive_c/windows/notepad.exe to /home/*/.wine/drive_c/windows/notepad.exe

[skosachiov]

Steps to check the functionality using wine applications as an example:

• fapolicyd.conf:

permissive = 1
...
trust = <pkg>db,file
integrity = sha256

• create two users: useradd -m jdoe; useradd -m jsmith

• login into GUI session as jdoe and run winecfg; login into GUI session as jsmith and run winecfg

• check that identical Wine structures are created, only regs differ: diff --brief -r /home/jdoe/.wine /home/jsmith/.wine

• note that our goal is to add only one set of trust hashes that will apply to all home directories

• file /etc/fapolicyd/rules.d/78-known-wine.rules

allow perm=any auid=0 : ftype=application/vnd.microsoft.portable-executable
allow perm=open all : path=/home/*/.wine/* ftype=application/vnd.microsoft.portable-executable trust=1
allow perm=open all : ftype=application/vnd.microsoft.portable-executable trust=1
deny_syslog perm=any all : ftype=application/vnd.microsoft.portable-executable

• add trust

/usr/local/sbin/fapolicyd-cli -f add /home/jdoe/.wine/ --trust-file wine-home.trust

• reload fapolicyd

• grep db

/usr/local/sbin/fapolicyd-cli -D | grep wine | grep notepad

• check output

filedb /home/*/.wine/drive_c/windows/notepad.exe 490403 338780f0cd76c8c04fb536c9397c32ae5f944e6750c87f087e455e4bda389abe
filedb /home/*/.wine/drive_c/windows/system32/notepad.exe 490403 338780f0cd76c8c04fb536c9397c32ae5f944e6750c87f087e455e4bda389abe

• login as jdoe, not su or sudo, run (or read) jdoe wine app, we want to get the magic MZ-bytes:

jdoe@localhost$ head -c 2 ~/.wine/drive_c/windows/notepad.exe
MZ

• login as jsmith, not su or sudo, run (or read) jsmith wine app, note that we did not create trust file for the jsmith wine folder, despite this:

jsmith@localhost$ head -c 2 ~/.wine/drive_c/windows/notepad.exe
MZ

• make some modification that should block the open operation, change the file name, change the hash, and read magic MZ:

jsmith@localhost$ cp -a ~/.wine/drive_c/windows/notepad.exe ~/.wine/drive_c/windows/notepad.exe.orig
jsmith@localhost$ echo " " >> ~/.wine/drive_c/windows/notepad.exe
jsmith@localhost$ head -c 2 ~/.wine/drive_c/windows/notepad.exe # NEW HASH
head: cannot open '/home/jsmith/.wine/drive_c/windows/notepad.exe' for reading: Operation not permitted
jsmith@localhost$ head -c 2 ~/.wine/drive_c/windows/notepad.exe.orig  # NEW NAME
head: cannot open '/home/jsmith/.wine/drive_c/windows/notepad.exe.orig' for reading: Operation not permitted

• It is worth noting that when blocking in the log we only get a wildcard, which does not give a complete picture of what is happening.

Nov 24 12:12:05 localhost fapolicyd[23477]: rule=23 dec=deny_syslog perm=open auid=1001 pid=24811 exe=/usr/bin/head : path=/home/*/.wine/* ftype=application/vnd.microsoft.portable-executable trust=0

[radosroka]

Hey, it seem to be a big amount of work.

It does make sense to put wildcards into path and exec rule attributes but the way you put them into trustdb won't work with integrity because there is just one hash for x files that match globing. What you can do is to extend CLI "add" and possibly others so it supports loading files with wildcards therefore each file will be in trustdb with coresponding hash.

I've changed your output little bit so take a look:

Steps to check:

• file /etc/fapolicyd/rules.d/78-known-wine.rules

allow perm=any auid=0 : ftype=application/vnd.microsoft.portable-executable
allow perm=open all : path=/home/*/.wine/* ftype=application/vnd.microsoft.portable-executable trust=1
allow perm=open all : ftype=application/vnd.microsoft.portable-executable trust=1
deny_syslog perm=any all : ftype=application/vnd.microsoft.portable-executable

• add trust

/usr/local/sbin/fapolicyd-cli -f add /home/jdoe/.wine*/ --trust-file wine-home.trust

• reload fapolicyd

• grep db

/usr/local/sbin/fapolicyd-cli -D | grep wine | grep notepad

• check output

filedb /home/jdoe/.wine1/drive_c/windows/notepad.exe 490403 338780f0cd76c8c04fb536c9397c32ae5f944e6750c87f087e455e4bda389abe
filedb /home/jdoe/.wine2/drive_c/windows/system32/notepad.exe 10000 61a9960bf7d255a85811f4afcac51067b8f2e4c75e21cf4f2af95319d4ed1b87

What do you think?

[skosachiov]

Sorry for the long comment. The previous comment has also been corrected and expanded.

I probably failed to get the message across. I'll use wine again as an example, although it doesn't have to be wine.
Вut that's how it's supposed to be - only one hash for the file path from the wildcard will work. I consider that e.g., forgive me lord, photoshop version for all users will be the same. It is unlikely that in a corporate environment it will be allowed to use different versions of software, but even if it is, there is a solution - different wine prefixes, i.e. folders. /home/jdoe/.wine/.photoshop_v1/ , /home/jsmith/.wine/.photoshop_v2/.

You give the example more about wildcards for adding hashes not for processing.
The key point of the pull request is "*" presented in the fapolicy-cli -D output:

filedb /home/*/.wine/drive_c/windows/notepad.exe 500434 05686ec26ed46c9f987951f39cba414c6bd81dc8d0b5f5e0ca3dafe2b8c72573
filedb /home/*/.wine/drive_c/windows/system32/notepad.exe 500434 05686ec26ed46c9f987951f39cba414c6bd81dc8d0b5f5e0ca3dafe2b8c72573
filedb /home/*/.wine/drive_c/windows/syswow64/notepad.exe 468149 b2aaf7d1084edcd6d4578024d8b885d8175f85501cc94cd9745517eb1de7ba15

It doesn't matter how the hashes get into the database. Securely, of course, but now the cli utility does not require modification as it seems to me. You can use bash for this job:

for i in {1,2}; do fapolicyd-cli -f add /home/jdoe/.wine$i --trust-file somewine$i.trust; done

fapolicyd-cli -D | grep notepad.exe

filedb /home/jdoe/.wine1/drive_c/windows/notepad.exe 500436 702356f0a16135b0e63c530318fa1f4a7857983be7eba5d42a5c2151c0ce0e54
filedb /home/jdoe/.wine1/drive_c/windows/notepad.exe.orig 500434 05686ec26ed46c9f987951f39cba414c6bd81dc8d0b5f5e0ca3dafe2b8c72573
filedb /home/jdoe/.wine1/drive_c/windows/system32/notepad.exe 500434 05686ec26ed46c9f987951f39cba414c6bd81dc8d0b5f5e0ca3dafe2b8c72573
filedb /home/jdoe/.wine1/drive_c/windows/syswow64/notepad.exe 468149 b2aaf7d1084edcd6d4578024d8b885d8175f85501cc94cd9745517eb1de7ba15
filedb /home/jdoe/.wine2/drive_c/windows/notepad.exe 500436 702356f0a16135b0e63c530318fa1f4a7857983be7eba5d42a5c2151c0ce0e54
filedb /home/jdoe/.wine2/drive_c/windows/notepad.exe.orig 500434 05686ec26ed46c9f987951f39cba414c6bd81dc8d0b5f5e0ca3dafe2b8c72573
filedb /home/jdoe/.wine2/drive_c/windows/system32/notepad.exe 500434 05686ec26ed46c9f987951f39cba414c6bd81dc8d0b5f5e0ca3dafe2b8c72573
filedb /home/jdoe/.wine2/drive_c/windows/syswow64/notepad.exe 468149 b2aaf7d1084edcd6d4578024d8b885d8175f85501cc94cd9745517eb1de7ba15

But in my case Information security specialists manually generate wine application trust files, and ansible automatically delivers trust files to client workstations. specialists may change real username to asterisk but it is not necessary . remediations-gendbuntu. Since integrating trusts into wine packages is quite problematic.

Obviously, may be some warning to administrator, that actual rules patterns /home/*/.wine/* will override some hashes e.g. /home/jdoe/.wine/notepad.exe hash will override /home/jsmith/.wine/nootepad.exe. But there is no big sense in this, because the wildcard rules can be added after hash adding. It is too difficult to reduce the probability of error. The administrator must understand what he is doing. Wildcard is always dangerous because it is wild.