Untrusting system trusted files

[jw3]

Question

How could fapolicyd's trust for a system-trusted file be revoked?

scenario

A vulnerability is discovered in a RPM installed file, where uninstall is not an option, and there is no upgrade available.

Can the file be blacklisted until it can be upgraded?

option 1

One option could be to add an ancillary trust entry with a junk hash, eg all 0s.

• How does that scale?
• Is it easy to understand/maintain when looking at the config file?

option 2

Another option would be to add a rule that explicitly denies the file.

• How does this scale?
• Generally the guidance is to avoid additional rules where possible, instead relying on trust.

option 3

Another option would be to write the lmdb trust database, directly evicting the trust entry.

• One issue is that fapolicyd reloads the database from the backend sources if they do not match.
  • Can it be updated to optionally skip the sync check when starting or when a reload is signaled?

What else is there?

[jw3]

I did a reference impl for option 3 here - https://github.com/jw3/fapolicyd/tree/skip_db_sync

This adds a daemon config setting to avoid db sync with the backend sources on reload or restart (still syncs on init).

Using our dev tool tdb we can inject or delete a trust record while fapolicyd is running, signal a reload through the pipe and see the changes applied.

Test setup

• In fapolicyd.conf set do_db_sync = 0.
• The first rule is set to reject execution of anything untrusted in the test dir /tmp/foo
  • deny_syslog perm=execute all : dir=/tmp/foo/ trust=0
  • open is allowed in this example so that we can read the file to add it to the trust db while fapolicyd runs
• Create an untrusted script, boom.sh, that just echos to the console and gets placed in /tmp/foo

1. try to run boom.sh => deny
2. add boom.sh to trust with tdb (verifying lmdb record counts before and after)
3. signal a reload to the daemon
4. try boom.sh => success
5. evict the record, reload, and observe deny

Writing to the pipe can be substituted with a daemon restart to achieve same results.

Test log

[vagrant@fedora ~]$ /tmp/foo/boom.sh 
-bash: /tmp/foo/boom.sh: /bin/bash: bad interpreter: Operation not permitted
[vagrant@fedora ~]$ ./tdb count
15737
[vagrant@fedora ~]$ ./tdb add /tmp/foo/boom.sh 
[vagrant@fedora ~]$ ./tdb count
15738
[vagrant@fedora ~]$ echo 1 > /run/fapolicyd/fapolicyd.fifo 
[vagrant@fedora ~]$ /tmp/foo/boom.sh 
boom!
[vagrant@fedora ~]$ ./tdb del /tmp/foo/boom.sh 
[vagrant@fedora ~]$ ./tdb count
15737
[vagrant@fedora ~]$ echo 1 > /run/fapolicyd/fapolicyd.fifo 
[vagrant@fedora ~]$ /tmp/foo/boom.sh 
-bash: /tmp/foo/boom.sh: /bin/bash: bad interpreter: Operation not permitted

Supports

• trust db management by third party applications
• simplified integration testing
• advanced use cases like eviction of records
• ...

Questions

• are there any other areas in the daemon that touch lmdb making this unsafe?
• are there reasons why this is not good, aka bad?
• ...

[jw3]

This sort of ties over into #226 when you think of additional use cases that could be handled by revoking or adding trust based on application logic, without the need to push such logic down into the daemon.

[radosroka]

I think that trying to stop the sync may break the system. You need to ensure that there will be no system update at the time. With not updated trustdb you cannot use updated binaries. And at the end of the update transaction rpm/dnf plugin will write 1 to the pipe.

I see two options to accomplish this:

1. create fapolicyd.ban file with the same format as fapolicyd.trust
2. create prefix for trust file entries that are untrusted

# cat /etc/fapolicyd/fapolicyd.trust
....
/opt/soft/xyz <size> <sha>
-/bin/ls <size> <sha>
...

[jw3]

Thanks @radosroka.

I think that trying to stop the sync may break the system.

I can see the problem posed by both the in-progress system update and the state of the system after the update. Significant.

The option to ban files sounds like it accomplishes what this topic was created for, and does it in a clean way.

-/bin/ls <size> <sha>

Prefixing is interesting.

[radosroka]

I just realized that it is not that simple with such prefix because it is possible to start fapolicyd with trust=rpmdb. Without trust=file ban will not work.

[jw3]

For posterity and visibility I'll open the original point as an issue on the daemon repo.

For the same reason I might submit that branch as a PR and you can poke holes in it up there too 😁

[radosroka]

This was addressed in fapolicyd by linux-application-whitelisting/fapolicyd#222.

[jw3]

Thanks @radosroka . It's good to update this discussion to close the loop on it.

Support for this new feature is being tracked in

• Support rpmdb filtering config #758