Describe the bug
Kubernetes Security policy missing remediation steps

The following controls have no remediation step:

• Container should not mount the Docker socket
• Container should not allow privilege escalation
• Container should not mount the CRI-O socket
• Container should not mount the containerd socket
• Container should use an immutable root filesystem
• Container should not run as root
• Pod should not run with hostNetwork
• Pod should not run with hostPID
• Pod should not run with hostIPC
• Container image pull should be consistent

Describe the bug
We currently run kernel checks on containers. This is noise as the user cannot fix these parameters. We should skip these checks.

Describe the bug
The query in the GitHub Org policy's Ensure repository has a code of conduct policy control should be looking for a code of conduct file at the org level, but even with that policy in place the query fails.

To Reproduce
Steps to reproduce the behavior:

1. cnspec scan github repo test-kitchen/test-kitchen --token SOME_TOKEN
2. ✕ Fail: B 70 Ensure repository has a code of conduct policy

Expected behavior
This should pass since the policy is there: https://github.com/test-kitchen/.github/blob/main/CODE_OF_CONDUCT.md

Screenshots or CLI Output

What is not working as you expected it?

The Kubernetes Best Practices by Mondoo has a few issues:

• not all queries have impacts
• groups are missing a title

The Kubernetes Cluster and Workload Security by Mondoo has a few issues:

• Kubernetes API Server is missing impacts

The corresponding query does not work if we define the configuration in a file in /etc/sudoers.d:

I would suggest to use sudo sudo -V instead.

Describe the bug
On Debian systems rcp cannot be disabled due to a dep from rpcbind.socket. We should include stopping and disabling rpcbind.socket as well in the remediation.

systemctl disable rpcbind
Warning: Stopping rpcbind.service, but it can still be activated by:
  rpcbind.socket

Describe the bug
When scanning a Fedora 36 container image the Linux baseline security policy's Ensure mail transfer agent is configured for local-only mode control throws this error:

[
  {
    "error": "cannot convert primitive with NO type information"
  },
  {
    "error": "cannot convert primitive with NO type information"
  },
  null
]

To Reproduce
Steps to reproduce the behavior:

1. cnspec scan docker image dokken/fedora-36

Describe the bug
The current test doesn't know how to handle multiple settings for PermitRootLogin. I already reported a bug in cnspec because it can't differentiate things like match groups. The policy gets a result of "no,no" because it sees it as two of the same option, so it fails the test.

This should loop over a list if it exists and ensure all of them are set to no. Ideally, cnspec would give you the match groups as collections of options, which can be tested in turn and reported individually.

To Reproduce
Steps to reproduce the behavior:

1. At the end of the file add this:
   Match Group games
   PermitRootLogin no
2. run cnspec shell, and query with: sshd.config.params[PermitRootLogin]
3. Observe the output being:

sshd.config.params[PermitRootLogin]: "no,no"

Expected behavior
That output should pass the test, but it does not, because it is looking for "no" and doesn't know how to handle multiple results.

Desktop (please complete the following information):

• OS: Linux/PopOS
• OS Version: 22.x

Describe the bug
Something weird is going on here with Ensure login and logout events are collected in the Linux Security policy on Debian that causes the control to fail even if the remediation steps are followed.

It has the query

if( platform.family.contains('debian') ) {
  command("auditctl -l") {
    stdout.contains("-w /var/log/faillog -p wa -k logins")
  }
} else {
  command("auditctl -l") {
    stdout.contains("-w /var/run/faillock -p wa -k logins")
  }
}
command("auditctl -l") {
  stdout.contains("-w /var/log/lastlog -p wa -k logins")
  stdout.contains("-w /var/log/tallylog -p wa -k logins")
}

and on debian we suggest adding the following lines to a auditd config file:

-w /var/log/lastlog -p wa -k logins

-w /var/log/tallylog -p wa -k logins

and

-w /var/log/faillog -p wa -k logins

I've added the following to /etc/audit/rules.d/50-logins.rules:

-w /var/log/lastlog -p wa -k logins
-w /var/log/tallylog -p wa -k logins
-w /var/log/faillog -p wa -k logins

The problem is event though I have /var/log/lastlog defined here the auditctl -l output is /var/run/lastlog:

-w /etc/selinux -p wa -k MAC-policy
-w /usr/share/selinux -p wa -k MAC-policy
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b64 -S rename,unlink,unlinkat,renameat -F auid>=1000 -F auid!=-1 -F key=delete
-a always,exit -F arch=b32 -S unlink,rename,unlinkat,renameat -F auid>=1000 -F auid!=-1 -F key=delete
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillog -p wa -k logins
-w /var/log/tallylog -p wa -k logins
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,delete_module -F key=modules
-a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=-1 -F key=mounts
-a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=-1 -F key=mounts
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=-1 -F key=perm_mod
-w /etc/sudoers -p wa -k scope
-w /etc/sudoers.d -p wa -k scope
-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k logins
-w /var/log/btmp -p wa -k logins
-w /var/log/sudo.log -p wa -k actions
-a always,exit -F arch=b64 -S sethostname,setdomainname -F key=system-locale
-a always,exit -F arch=b32 -S sethostname,setdomainname -F key=system-locale
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/network -p wa -k system-locale
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=time-change
-a always,exit -F arch=b32 -S stime,settimeofday,adjtimex -F key=time-change
-a always,exit -F arch=b64 -S clock_settime -F key=time-change
-a always,exit -F arch=b32 -S clock_settime -F key=time-change
-w /etc/localtime -p wa -k time-change

This causes this control to always fail on my Debian host.

Describe the bug
There are a few things we can extend cnquery to check and then add to this policy per: https://about.gitlab.com/blog/2023/05/31/securing-your-code-on-gitlab/ as well as some common sense items from the API.

Groups:

• Blocking forking repos outside the project
• Enable delayed project deletion
• Limit creating subgroups to owners
• Limit creating projects to owners

Projects:

• Disable treating skipped pipelines as successful
• Only allow merges if pipelines succeed
• Use separate caches for protected branches.
• Disable public builds
• Set the releases access level to private
• Use separated caches for protected branches
• Disable shared runners

The current DKIM check in the email security policy allows you to set a property with a list of DKIM selectors. This is a good initial version, and should provide adequate support for simple setups.

However, a lot of organizations have multiple sending domains, with varying DKIM keys, and in some organizations, those keys are identified by the date they were created for ease of tracking, rotation, etc. This could potentially result in overlapping selectors across multiple domains.

That means, if say, I want to ensure that we only have a particular DKIM selector for domain X.domain.com, and not Y.domain.com I can't assert that in my policy without having them in separate spaces (or, of course, writing my own custom policy.) If I remove a key, I might also be removing a selector from monitoring that's still being used.

I would propose making this a map (if properties support those) of domains => [valid selectors].

Describe the bug
cnspec's policy fails to account for using a data source for policy like this:

data "aws_iam_policy_document" "some_policy" {
  statement {
    actions = [ ]
    resources = ["*"]
  }
}

resource "aws_iam_policy" "some_policy" {
  name  = "SomePolicy"
  ...

  policy = data.aws_iam_policy_document.some_policy.json
}

To Reproduce
Steps to reproduce the behavior:

1. Write up some terraform with an iam policy resource and a data resource for the policy as described above.
2. run cnspec scan terraform against it

Expected behavior
most likely, it should have an additional exception for when the value is a simple string - because in addition to data sources it's not uncommon to use file() or templatefile() functions here.

There should probably be another check here that looks for:
terraform.datasources.where(nameLabel == "aws_iam_policy_document") and runs similar checks. Perhaps file() could do something similar, but templatefile probably isn't something you can work with outside of a plan.

Desktop (please complete the following information):

• OS: Linux
• OS Version: PopOS

Additional context

The check defined here has this query:

terraform.resources.where( nameLabel  == "aws_iam_policy" && arguments["policy"] != null  ) {
  arguments["policy"].where( _["Statement"] != null) {
    _["Statement"] {
      # Resource is either not * or DENY is used (where wildcard is great)
      _["Resource"] != "*" || _["Effect"].upcase == "DENY"
    }
  }
}

This assumes that the policy will be inline - but if you're using a datasource it'll look like this instead:

arguments {
  ...
  policy: "data.aws_iam_policy_document.some_policy.json"
}

This results in an error like this:

! Error: Ensure IAM policy do not use wildcards and instead apply the principle of least privilege
Message: 1 error occurred:
* 1 error occurred:
* cannot find function '[]' for type 'stringslice'

This is a tracking issue to wire up automation so that a release in this repo results in policies in the public hub. Don't worry about where that automation lives or where this issue is. It's just to track the TODO item as part of the maturity of the public registry product.

Describe the bug
E.g., the policy terraform-gcp-security-gke-enable-auto-repair is not applied to this GKE config:

resource "google_container_node_pool" "node_pool" {
  name       = "mondoo-operator-pool-${random_string.suffix.result}"
  location   = "us-central1-a"
  cluster    = google_container_cluster.cluster.id
  node_count = 1

  node_config {
    spot         = true
    machine_type = "e2-standard-2"
  }
}

The config block management is missing. So, the setting is missing and the policy should fail.

This applies to some more policies.

To Reproduce
Steps to reproduce the behavior:

1. Enable terraform GCP policy
2. Run cnspec against a terraform file containing above node pool.
3. See the above control is skipped.

Expected behavior
The control should fail.

Desktop (please complete the following information):

• OS: Ubuntu 22.04
• cnspec version: 7.7.1

Describe the bug
There is a check in AWS Security that has TODO remediation steps. We need to fill those out.

https://github.com/mondoohq/cnspec-policies/blob/main/core/mondoo-aws-security.mql.yaml#L1144

In Google Workspace Security by Mondoo it has instructions for running the query pack, but it's not a query pack. I think this was copied from the query pack.

Describe the bug

cnspec scan azure fails to compile the official Azure policies with a strange cannot find resource for identifier 'microsoft' error.

To Reproduce

• download cnspec from GitHub releases
• login to Azure CLI as Global Reader
• run cnspec scan azure

Expected behavior

cnspec should test the mondoo-azure-security.mql.yaml policy against my Azure tenant.

Screenshots or CLI Output

❯ az login --use-device-code
❯ ./cnspec shell azure
→ no Mondoo configuration file provided, using defaults
→ selected asset asset="Azure subscription Pay per Use (XXXXXX)" selection=0
→ connected to Azure Subscription
...
cnspec> azure.subscription.name
azure.subscription.name: "Pay per Use (XXXXXX)"
cnspec> exit
❯ ./cnspec scan azure
→ no Mondoo configuration file provided, using defaults
! No credentials provided. Switching to --incognito mode.
→ discover related assets for 1 asset(s)
...
 0/3 scanned 3/3 errored                                   
...
error: failed to compile fetched bundle: failed to validate query '//registry.mondoo.com/namespace/mondoohq/queries/mondoo-azure-security-ensure-multifactor-authentication-is-enabled-for-all-users-in-administrative-roles': failed to compile query 'microsoft.security.latestSecureScores.controlScores.one( _['controlName'] == 'AdminMFAV2' && _['score'] == 10 )': cannot find resource for identifier 'microsoft'
failed to validate query '//registry.mondoo.com/namespace/mondoohq/queries/mondoo-azure-security-ensure-that-between-two-and-four-global-admins-are-designated': failed to compile query 'microsoft.rolemanagement.roleDefinitions.where(displayName == "Global Administrator").all(assignments.length > 1 && assignments.length <= 4)': cannot find resource for identifier 'microsoft'
failed to validate query '//registry.mondoo.com/namespace/mondoohq/queries/mondoo-azure-security-ensure-multifactor-authentication-is-enabled-for-all-users-in-all-roles': failed to compile query 'microsoft.security.latestSecureScores.controlScores.one( _['controlName'] == 'MFARegistrationV2' &&  _['score'] == 9)': cannot find resource for identifier 'microsoft'
failed to validate query '//registry.mondoo.com/namespace/mondoohq/queries/mondoo-azure-security-enable-azure-ad-identity-protection-user-risk-policies': failed to compile query 'microsoft.security.latestSecureScores.controlScores.one( _['controlName'] == 'UserRiskPolicy' && _['score'] == 7 )': cannot find resource for identifier 'microsoft'
failed to validate query '//registry.mondoo.com/namespace/mondoohq/queries/mondoo-azure-security-enable-azure-ad-identity-protection-sign-in-risk-policies': failed to compile query 'microsoft.security.latestSecureScores.controlScores.one( _['controlName'] == 'SigninRiskPolicy' && _['score'] == 7 )': cannot find resource for identifier 'microsoft'
failed to validate query '//registry.mondoo.com/namespace/mondoohq/queries/mondoo-azure-security-ensure-security-defaults-is-enabled-on-azure-active-directory': failed to compile query 'microsoft.policies.identitySecurityDefaultsEnforcementPolicy["isEnabled"] == true': failed to compile: cannot find resource for identifier 'microsoft'
...

Desktop (please complete the following information):

• OS: Arch Linux
• OS Version: na
• Browser if applicable: na
• Browser Version: na

Additional context

Tested with cnspec 9.4.0, 9.5.0 and 9.5.1.

When you do not send mail from a domain, it is best practice to have a setup like:

• SPF: -all
• DMARC: policy to reject with strict spf/dkim alignment
• A wildcard record of *._domainkey.domain.com with the value "v=DKIM1;p="

And if it doesn't receive mail either, a null MX record ("domain.com IN MX .")
The current DKIM check in the email security policy would technically already allow you to check that the selector exists but would think that the record is misconfigured. A variant that can detect this situation and recognize it as a valid configuration would be helpful.

Describe the bug
A clear and concise description of what the bug is.

This query is missing an impact as seen in the registry:

The TLS Baseline policy specifes the following scores for ages:

        case tls.certificates.first.expiresIn.days > 150: score(100);
        case tls.certificates.first.expiresIn.days > 120: score(70);
        case tls.certificates.first.expiresIn.days > 90: score(50);
        case tls.certificates.first.expiresIn.days > 60: score(20);
        case tls.certificates.first.expiresIn.days > 30: score(9);
        default: score(0);

These expiration assume a traditional PKI with 1year or longer certificate lifecycles which aren't common any longer. Thanks to cloud certificate managers, such as Google Cert Manager and Lets Encrypt use a 90 day certificate which is renewed at the 30 day mark, see:

• https://letsencrypt.org/2015/11/09/why-90-days.html
• https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs

"Google Cloud provisions managed certificates valid for 90 days. About one month before expiry, the process to renew your certificate automatically begins."

Therefore I propose a new scheme:

        case tls.certificates.first.expiresIn.days > 30: score(100);
        case tls.certificates.first.expiresIn.days > 21: score(50);
        case tls.certificates.first.expiresIn.days > 7: score(20);
        case tls.certificates.first.expiresIn.days > 7: score(9);
        default: score(0);

Is your feature request related to a problem? Please describe.
When we raise a problem we're telling a user to interrupt their normal work stream to resolve a problem we think is important. We need to make sure we convey that importance to the user though. A description field should include two things:

• What we're checking
• Why it's important to fix this

Describe the solution you'd like
Audit all desc fields and make sure they explain what the control checks and why it matters to fix the problem.

Describe the bug
The Linux policy has a check Ensure secure permissions on /etc/passwd- are set that has the user just change the permission on this file. The problem is any changes to a user will revert the permissions. We need an updated remediation step that will stick. The same problem most likely exists for the /etc/group- check as well.

Describe the bug
My Ubuntu Laptop fails the check "Ensure permissions on bootloader config are configured".

The remediation states:

**OR If the system uses UEFI, edit /etc/fstab and add the fmask=0077 , uid=0 , and gid=0 options:

But my /etc/fstab has the following entry for efi:

UUID=A54C-EF7A  /boot/efi       vfat    umask=0077      0       1

This results in fmask being set as requested:

mount | grep "/boot/efi" 
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

So, I think this line should also check for umask:
https://github.com/mondoohq/cnspec-policies/blob/main/core/mondoo-linux-workstation-security.mql.yaml#L214

To Reproduce
Steps to reproduce the behavior:

1. Start a VM with Ubuntu 22.04
2. Run the workstation policy for it
3. Check results

Expected behavior
My Laptop should pass the check.

Desktop (please complete the following information):

• OS: Ubuntu 22.04

Describe the bug
GitHub branch protection rules checks do not work. If branch protection is not configured the individual branch protection rules checks pass.

To Reproduce
Steps to reproduce the behavior:

1. Create repo
2. Leave branch protection off
3. scan repo

Expected behavior
Each branch protection rule should fail if branch protection is not configured.

Screenshots or CLI Output
If applicable, add screenshots or the CLI output to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. macOS]
• OS Version: [e.g. 13.0]
• Browser if applicable: [e.g. Chrome, Firefox]
• Browser Version: [e.g. 106]

Additional context
Add any other context about the problem here.

Describe the bug
In the GitHub Org security policy the remediation steps for Organization should have a verified domain attached control are actually for setting up MFA.

To Reproduce
Steps to reproduce the behavior:

1. Scan an org
2. Check the results

Expected behavior
Instructions on how to validate an org to a domain.

Screenshots or CLI Output

Describe the bug
The Linux Security policy's Ensure IP forwarding is disabled control includes remediation steps that do not work on Debian.

To Reproduce

1. Get a sweet Debian box
2. Add the sysctl configs to the config:

net.ipv4.ip_forward = 0

net.ipv6.conf.all.forwarding = 0

3. Run the sysctl commands provided:

sysctl -w net.ipv4.ip_forward=0

sysctl -w net.ipv6.conf.all.forwarding=0

sysctl -w net.ipv4.route.flush=1

sysctl -w net.ipv6.route.flush=1
```
4. Scan the system

**Expected behavior**
Things pass.

Describe the bug
#406

The changes included in this PR break the server startup.

To Reproduce
Steps to reproduce the behavior:

1. Add policy changes to server
2. Try to start
3. Note the error

Expected behavior
Server should start.

Is your feature request related to a problem? Please describe.
If GitHub actions are being used then dependabot should be set up to keep them up to date.

Describe the solution you'd like
When a .github/workflows directory exists there should be a dependabot setup for GitHub Actions

Currently the mondoo-windows-security is missing impact scores

We have updated the checks to use subcategoryguid instead of a name to avoid different checks for different languages. This should be adapted to the powershell scripts as well.

Example:

https://github.com/mondoohq/cnspec-policies/blob/main/core/mondoo-windows-security.mql.yaml

        Auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable

Should use the guid just like the check:

  auditpol.where(subcategoryguid == "0CCE9217-69AE-11D9-BED3-505054503030").list != []

When opening some assets we can only see two policies, when we expect three. Many others show correctly.
The one missing is "Windows Security", but we can also see that in top recommendation there are for "Windows Security".
Please see attached image.

Also notice that the score become an A with this issue.

To Reproduce
Open an asset.

Expected behavior
Expect to see the 3 policies, and the score affected by it.

Screenshots or CLI Output

Same image as above.

Desktop (please complete the following information):

• OS: Windows
• OS Version: 10
• Browser if applicable: Edge
• Browser Version: 120.0.2210.144 64bit

Additional context

The Google Workspace Security by Mondoo policy needs descriptions with audit and remediation instructions.

Describe the bug
The remediation steps in the Linux Security policy's Ensure that strong Key Exchange algorithms are used control are unique per version of OpenSSH, but we never tell the user how to find out what version they are running. Without this information, there isn't enough data for them to move forward.

Remediation steps:

There are also no auditing instructions for this control.

Expected behavior
We should have them run sshd -h (yes this is a bogus command, but it works) so that they can find out what version of OpenSSH they're running.

Describe the bug
When scanning an org (test-kitchen) where MFA is required the GitHub org control Enable Two-factor authentication for all users in the organization is failing.

To Reproduce
Steps to reproduce the behavior:

1. cnspec scan github org test-kitchen --token foo
2. See failure of MFA check

Expected behavior
This query should pass here.

Screenshots or CLI Output

Describe the bug
"Azure AD" will be renamed to "Azure Entra ID":

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/azure-ad-is-becoming-microsoft-entra-id/ba-p/2520436

Expected behavior
Our rules shouldn't show "Azure AD" anymore.

Describe the bug
We need to add impact scores to this policy:

Describe the bug
The remediation steps in the Linux Policy's Ensure ICMP redirects are not accepted control do not resolve the error.

3 of the 4 queries are ok, but not all:

To Reproduce
Steps to reproduce the behavior:

1. Add the systctl configs to the file as requested:

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv6.conf.all.accept_redirects = 0

net.ipv6.conf.default.accept_redirects = 0

2. Run the systclt commands as requested:

sysctl -w net.ipv4.conf.all.accept_redirects=0

sysctl -w net.ipv4.conf.default.accept_redirects=0

sysctl -w net.ipv6.conf.all.accept_redirects=0

sysctl -w net.ipv6.conf.default.accept_redirects=0

sysctl -w net.ipv4.route.flush=1

sysctl -w net.ipv6.route.flush=1

4. Scan the system

Expected behavior
The control should pass after implementing the remediation steps

Describe the bug
The Linux Security policy's Ensure secure permissions on /etc/group- are set lacks the action to determine if this control is worth checking for my organization. The description simply states:

The /etc/group- file contains a backup list of all the valid groups defined in the system.

There's no information on what the permissions should even be and no audit instructions.

Expected behavior
We should be selling people on why this control is important.

Screenshots
N/A