Bug 2157975

Summary:	Fapolicyd rules not working for SAP
Product:	Red Hat Enterprise Linux 8	Reporter:	Moustafa Harbi <mharbi>
Component:	fapolicyd	Assignee:	Radovan Sroka <rsroka>
Status:	NEW ---	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	8.7	CC:	cbrune, lvrabec, rsroka, ssamaved
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---	Flags:	cbrune: needinfo+ ssamaved: needinfo? (rsroka) mharbi: needinfo? (ssamaved) cbrune: needinfo+ cbrune: needinfo? (ssamaved) ssamaved: needinfo? (mharbi) ssamaved: needinfo? (rsroka)
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Moustafa Harbi 2023-01-03 19:32:29 UTC

Description of problem:
- Fapolicyd rules are configured for SAP but denials are still shown.

Version-Release number of selected component (if applicable):
- Red Hat Enterprise Linux release 8.7 (Ootpa)
- fapolicyd-1.1.3-8.el8.x86_64
- SAP is installed

How reproducible:
- Always

Steps to Reproduce:
1. Install SAP on RHEL 8.
2. Install Fapolicyd then run the daemon in permissive mode.
3. Generate the rules to allow SAP binaries and libraries.
4. Restart the fapolicyd service and check the denials again -> binary is still denied.

Actual results:
- Denials are seen although there are rules to allow the execution.

Expected results:
- Application execution should hit the rules and no denials shall be seen.

Additional info:

- 2 rules are configured to allow "sapuxusergetrtinfo" executable to run, however it's still denied:

   ~~~
   $ grep sapuxusergetrtinfo 0050-fapolicyd-cli_list
   65. allow perm=execute exe=/usr/bin/ksh93 trust=0 :   path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable trust=0
   69. allow perm=execute exe=/usr/bin/tcsh trust=0 :   path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable trust=0

   $ grep -i deny 0080-fapolicy.output2 | cut -d ' ' -f1,2,3,4,6,7,8,9 | sort | uniq | grep sapuxusergetrtinfo
   rule=2060 dec=deny_audit perm=execute auid=-1 exe=/usr/bin/ksh93 : path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable
   rule=2060 dec=deny_audit perm=execute auid=-1 exe=/usr/bin/tcsh : path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable
   ~~~

- Checking the rule #2060:

   ~~~
   $ grep -iR 2060 0050-fapolicyd-cli_list
   2060. deny_audit perm=execute all : all
   ~~~

- This rule is originating from 90-deny-execute.rules:

   ~~~
   $ cat 90-deny-execute.rules
   # Deny execution for anything untrusted
   deny_audit perm=execute all : all
   ~~~

- It seems odd hence the rules are already configured and should be matching before the deny. We need to investigate this in a greater detail hence I can see some mount change messages in fapolicy.output

Comment 1 Radovan Sroka 2023-01-04 09:51:54 UTC

I have a strong feeling that you don't need so many rules.

Is the SAP installed via RPM?

If yes, then everything should be automatically trusted.
If not, then you can put all the files to the trustdb to mark them trusted.

If you will have ale the SAP files trusted you should be ok with the default ruleset(more/less).



   ~~~
   $ grep sapuxusergetrtinfo 0050-fapolicyd-cli_list
   65. allow perm=execute exe=/usr/bin/ksh93 trust=0 :   path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable trust=0
   69. allow perm=execute exe=/usr/bin/tcsh trust=0 :   path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable trust=0

   $ grep -i deny 0080-fapolicy.output2 | cut -d ' ' -f1,2,3,4,6,7,8,9 | sort | uniq | grep sapuxusergetrtinfo
   rule=2060 dec=deny_audit perm=execute auid=-1 exe=/usr/bin/ksh93 : path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable
   rule=2060 dec=deny_audit perm=execute auid=-1 exe=/usr/bin/tcsh : path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable
   ~~~

Perhaps these exes and paths are trusted so that's why it does not match -> trust=1? 
Just guessing...

Comment 2 Moustafa Harbi 2023-01-04 10:05:10 UTC

@rsroka 

Correct, not all these rules are needed. There are 2 concerns here:

1. If we enable file based trust, do we need it for the executables or also the shared libraries installed by SAP?
2. Hence trusted files uses SHA256 and file size for verification, would these impose a heavy load on the system for a software like SAP (many executables, plenty of libs, excessive usage of system calls,..)?

Comment 3 Radovan Sroka 2023-01-04 11:17:13 UTC

(In reply to Moustafa Harbi from comment #2)
> @rsroka 
> 
> Correct, not all these rules are needed. There are 2 concerns here:
> 
> 1. If we enable file based trust, do we need it for the executables or also
> the shared libraries installed by SAP?
> 2. Hence trusted files uses SHA256 and file size for verification, would
> these impose a heavy load on the system for a software like SAP (many
> executables, plenty of libs, excessive usage of system calls,..)?

And do you now how the SAP files are installed?

If not by rpm, then yes, you need to add libraries to the trustdb as well.
If you are not using integrity these sizes and hashes are not used 
in fapolicyd and the only important part is a path so there is no problem with that.

I would point out the opposite, when you reduce the number of rules you can enhance
the performance. Iterating over the thousands of rules can take some time.
On the other hand access by key to the trustdb is really fast.

Comment 4 Radovan Sroka 2023-01-20 13:58:31 UTC

(In reply to Radovan Sroka from comment #3)
> (In reply to Moustafa Harbi from comment #2)
> > @rsroka 
> > 
> > Correct, not all these rules are needed. There are 2 concerns here:
> > 
> > 1. If we enable file based trust, do we need it for the executables or also
> > the shared libraries installed by SAP?
> > 2. Hence trusted files uses SHA256 and file size for verification, would
> > these impose a heavy load on the system for a software like SAP (many
> > executables, plenty of libs, excessive usage of system calls,..)?
> 
> And do you now how the SAP files are installed?
> 
> If not by rpm, then yes, you need to add libraries to the trustdb as well.
> If you are not using integrity these sizes and hashes are not used 
> in fapolicyd and the only important part is a path so there is no problem
> with that.
> 
> I would point out the opposite, when you reduce the number of rules you can
> enhance
> the performance. Iterating over the thousands of rules can take some time.
> On the other hand access by key to the trustdb is really fast.

Would you consider to move to file based trust?

   ~~~
   $ grep sapuxusergetrtinfo 0050-fapolicyd-cli_list
   65. allow perm=execute exe=/usr/bin/ksh93 trust=0 :   path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable trust=0
   69. allow perm=execute exe=/usr/bin/tcsh trust=0 :   path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable trust=0

   $ grep -i deny 0080-fapolicy.output2 | cut -d ' ' -f1,2,3,4,6,7,8,9 | sort | uniq | grep sapuxusergetrtinfo
   rule=2060 dec=deny_audit perm=execute auid=-1 exe=/usr/bin/ksh93 : path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable
   rule=2060 dec=deny_audit perm=execute auid=-1 exe=/usr/bin/tcsh : path=/usr/sap/hostctrl/exe/sapuxusergetrtinfo ftype=application/x-executable
   ~~~

Does it work when you remove 'trust=0' from object and subject side?

Comment 5 Radovan Sroka 2023-06-16 09:12:05 UTC

Is this still relevant?

Comment 8 Christoph Brune 2023-07-18 06:58:44 UTC

Yes, we can test this here in Walldorf. I will forward the ticket to my team.

Comment 9 ssamaved 2023-07-18 12:33:46 UTC

@rsroka : We have setup an internal 8.7 server and had fapolicyd installed to work on this.

1. The default version of fapolicyd was "fapolicyd-1.1.3-8.el8_7.1.x86_64" as opposed to the version "fapolicyd-1.1.3-8.el8.x86_64" requested in this Bug. Is this ok?
2. When the product is mentioned as SAP, is it assumed to be "SAP HANA" or is there another product (say Netweaver, S4, etc.) that is in question here?

Comment 10 Moustafa Harbi 2023-07-18 13:15:44 UTC

@ssamaved 


1. Yes. If rules are working, it shouldn't matter whether it's RHEL 7 or 8.
2. Product was SAP HANA.

Comment 13 ssamaved 2023-07-28 09:14:18 UTC

@rsroka : A RHEL 8.7 server with HANA and fapolicyd had been setup and shared with @mharbi.

Will await further feedback (customer has some extra functions on their env it seems).