Parliament

Latest version: v1.6.2

Safety actively analyzes 629908 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 5 of 7

0.4.7

The big feature of this release it adds community auditors from kmcquade . These currently are:
- Credentials exposure - Policy grants access to API calls that can return credentials to the user
- Permissions management actions - Allows the principal to modify IAM, RAM, identity-based policies, or resource based policies.
- Privilege escalation - Actions contain a combination of Privilege Escalation actions established by Rhino Security Labs

These are off by default for now, but can be enabled with `--include-community-auditors`

This fixes a bug when checking the results of `get-account-authorization-details` (thanks to kmcquade again!)

This also adds a function `get_allowed_actions` which returns a list like `['s3:putobject']` for every action allowed. This likely will hurt performance when a `*` policy is involved. This function is currently used by the community auditors and is one of the reasons I don't have those on by default yet.

0.4.6

Updates the is_glob_function to account for some special cases. Code from Paul McGuire again in https://github.com/duo-labs/parliament/issues/36#issuecomment-574463958

0.4.4

- Adds `is_glob_match` function from Paul McGuire from his comment here https://github.com/duo-labs/parliament/issues/36#issuecomment-574001764 This massively cleans up the mess that `is_arn_match` had become.
- Fixes a unit test that was including a check for a private auditor, and avoids testing against private auditors for the other tests.
- Updates the privilege data.
- Fixes the script that collects the privilege data so it can actually be run.

0.4.3

Minor fix (49) to improve identification of privileges being granted.

0.4.2

The big change this release was improving the logic for identifying which actions were allowed. Previously, if you had the following, it would not identify `s3:GetObject` as being allowed, because it saw an `Allow` and a `Deny` and did not take into consideration the `Condition`:


{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::secretbucket/*"
},
{
"Effect": "Deny",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::secretbucket/*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}


Now the logic identifies `s3:GetObject` as being allowed, because it only counts a `Deny` against the `Allow` if the `Deny` has no `Condition`. This should better handle possible tricks someone might do to get around a custom auditor someone might write (for example, the sensitive bucket auditor in the docs would have been tricked by this previously).

The unit tests should also be more robust, and a bug was fixed with how Bool's are checked to ensure they are being matched against true and false values.

0.4.1

You can now specify a directory for your private auditors, and instructions are provided on how to include your own unit tests for these. https://github.com/duo-labs/parliament#unit-tests-for-private-auditors

Some minor fixes to the existing tests to ensure they don't break when you have your own private auditors.

Page 5 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.