RHEL8/STIGs/aide.conf OwnerMode entry errors

JohnBoyNC · 03-08-2021, 06:57 AM

RHEL8 Final STIG: Vul ID: V-230552 Requires this entry in /etc/aide.conf:

VarFile = OwnerMode+n+l+X+acl
(I've placed it on Line 328 of /etc/aide.conf)

That entry breaks aide:
aide --check
328:Error in expression:OwnerMode
Configuration error

aide -C -V255 returns:
328:Equrule
328:Error in expression:OwnerMode
Configuration error

Modifying the rule (deleting parts one at a time) still throws the same error.

Looking for a clue/hint/whatev from somebody smarter than me. There's precious little info (besides the docs) out there.

Thanks.

JockVSJock · 03-12-2021, 12:58 PM

What if you comment out Line 328, what happens if you run

Code:

aide --check

Did you back up the vanilla file, aide.conf before making any changes? If so, overlay the file and run the check again...I always backed up any files first before making changes.

Your right in there isn't much details with it:

https://www.stigviewer.com/stig/red_...nding/V-230552

It is a Low, do you have to implement the Low STIGs?

JohnBoyNC · 03-12-2021, 09:46 PM

Thanks for the reply.

Comment out Line 328 and it runs fine.

Since I've been doing Unix since SunOS 4.13, of course I made backups.

And this is on government systems, so yep, must do CAT 3's as well as 1's and 2's.

Commented out this line and having SecOps fwd the issue back to the "genius" that wrote the STIG for review/clarification/modification.

JockVSJock · 03-13-2021, 10:58 AM

Quote:

Originally Posted by JohnBoyNC

And this is on government systems, so yep, must do CAT 3's as well as 1's and 2's.

Been there, done that...and got that t-shirt. My leadership did get Linux, so after a few years, I left.

Can't believe you have to do CAT 3. I used to work for DoD and we were only required to do CAT1 and CAT2. What part of the Gov't do you work for. You can send me a PM is your okay with that.

Quote:

Originally Posted by JohnBoyNC

Commented out this line and having SecOps fwd the issue back to the "genius" that wrote the STIG for review/clarification/modification

Agreed, this STIG is poorly written, like a lot of them. Hopefully this isn't on a production RHEL system?

JohnBoyNC · 03-13-2021, 09:33 PM

Won a new contract and the government entity (DoD "Logistical"-type agency) wants to upgrade from current RHEL7 to 8 for DEV/Stage/PROD. There are no SPEL (STIG-Partitioned Enterprise Linux) masters available yet for RHEL8 that meet the Final STIG recently issued, so I'm creating a master/golden image from scratch. Biggest headaches have been (1) poorly written/researched STIG requirements and (2) creating bootable encrypted volumes (LUKS or non-LUKS) for virtual instances in the cloud (AWS). Having issues getting the instances to auto-decrypt the volumes on boot. Nearly there, but it's been a "head banger" journey.

Side Note: Found a GitHub project that created a 250 item script to do most of the donkey work for STIG required settings. That alone saved days of my time. (https://github.com/RedHatGov/rhel8-stig-latest)

scottieH · 05-17-2021, 05:49 PM

I'm looking at the man pages for AIDE.

Code:

# Here are all the things we can check - these are the default rules
   #
   #p:      permissions
   #ftype:  file type
   #i:      inode
   #n:      number of links
   #l:      link name
   #u:      user
   #g:      group
   #s:      size
   #b:      block count
   #m:      mtime
   #a:      atime
   #c:      ctime
   #S:      check for growing size
   #I:      ignore changed filename
   #md5:    md5 checksum
   #sha1:   sha1 checksum
   #sha256: sha256 checksum
   #sha512: sha512 checksum
   #rmd160: rmd160 checksum
   #tiger:  tiger checksum
   #haval:  haval checksum
   #crc32:  crc32 checksum
   #R:      p+ftupe+i+l+n+u+g+s+m+c+md5
   #L:      p+ftype+i+l+n+u+g
   #E:      Empty group
   #>:      Growing file p+ftype+l+u+g+i+n+S
   #The following are available if you have mhash support enabled:
   #gost:   gost checksum
   #whirlpool: whirlpool checksum
   #The following are available and added to the default groups R, L and >
   #only when explicitly enabled using configure:
   #acl:    access control list
   #selinux SELinux security context
   #xattrs:  extended file attributes
   #e2fsattrs: file attributes on a second extended file system

   # You can also create custom rules - my home made rule definition goes like this
   #
   MyRule = p+i+n+u+g+s+b+m+c+md5+sha1

https://aide.github.io/doc/#config

I don't see OwnerMode anywhere. So, unless you define it as a custom rule, it won't work.

UPDATE
I the STIG says to run this command:

Code:

$ sudo egrep "[+]?acl" /etc/aide.conf

I ran it on my machine and I do not have the line 'VarFile = OwnerMode+n+l+X+acl'

Here is the rest of the text:

Code:

If the "acl" rule is not being used on all selection lines in the "/etc/aide.conf" file, is commented out, or ACLs are not being checked by another file integrity tool, this is a finding.

It is NOT saying you need to have the specific line 'VarFile = OwnerMode+n+l+X+acl' in your config file.

My grep shows something like this:

Code:

FIPSR=p+i+...+acl+...+sha256
ALL=FIPSR+acl+...
NORMAL=FIPSR+sha512
DIR=p+i+...+acl+...
and so on

Farther down in the config file, you'll see lines something like this:

Code:

/bin NORMAL
...
/etc/fstab NORMAL

Since the NORMAL rule contains the FIPSR rule. which contains acl rule, anything with NORMAL is using the acl rule, which meets the requirement.

My scanner isn't smart enough to know this, so I always get a finding. I write it up as a false finding and show that the config file is correct.

Alternative
Add '+acl' to all of the lines that are supposed to have it. (Note, not all are. Ex. log files).
To do this, you config file would then look something like this:

Code:

/bin NORMAL+acl
...
/etc/fstab NORMAL+acl

Although, it's a bit of a PITA. If you do this, it is possible you'll get another finding that the aid.conf file was modified after install.

JohnBoyNC · 05-17-2021, 10:10 PM

@scottieH Really appreciate the work you put into your answer. My original question said "looking for somebody smarter than me." Seems to be you!

I'll give your suggestions a shot tomorrow morning; everything you recommend sounds logical. I'll just have to wordsmith a good response to SecOps when they want "proof" that this is a good alternative. The "genius" who dreams up these Vulnerability "requirements and their fixes" needs to do some more homework.

Again, truly appreciate your input.

scottieH · 05-18-2021, 11:28 AM

Quote:

Originally Posted by JohnBoyNC

I'll just have to wordsmith a good response to SecOps when they want "proof" that this is a good alternative. The "genius" who dreams up these Vulnerability "requirements and their fixes" needs to do some more homework.

Again, truly appreciate your input.

YW. Glad to help!

Here is my rough draft that I'm using:

Code:

These plugins are looking for the rules 'acl', xattrs', and 'sha512' on each configuration item. However, it is possible that the sought after configuration is embedded in an alias. In which case, these plugins will give a false positive.

A search of the aide config file shows the following aliases assigned to these values:
[Insert the results of: grep -E 'acl|xattrs|sha512' /etc/aide.conf]

Thus the LSPP (or what ever alias you use) satisfies all 3 of these plugins, yet it shows as a finding

Good Luck!