From 005ca1713a78650cf6683bf873d0e3679589c6e7 Mon Sep 17 00:00:00 2001 From: Firstyear Date: Thu, 25 Jan 2024 09:08:54 +1000 Subject: [PATCH] 1222 what rights does anonymous have (#2436) Document the default access that anonymous has, as well as default access controls and permission groups. --- book/src/SUMMARY.md | 3 ++ book/src/access_control/intro.md | 74 ++++++++++++++++++++++++++++++++ book/src/accounts/anonymous.md | 50 +++++++++++++++++++++ book/src/accounts/intro.md | 36 ---------------- 4 files changed, 127 insertions(+), 36 deletions(-) create mode 100644 book/src/access_control/intro.md create mode 100644 book/src/accounts/anonymous.md diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index def94de54..e40d88951 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -26,6 +26,7 @@ - [Authentication and Credentials](accounts/authentication.md) - [Groups](accounts/groups.md) - [Service Accounts](accounts/service.md) + - [Anonymous](accounts/anonymous.md) - [Account Policy](accounts/policy.md) - [POSIX Accounts and Groups](accounts/posix.md) @@ -53,6 +54,8 @@ - [FreeIPA](sync/freeipa.md) - [LDAP](sync/ldap.md) +- [Access Control](access_control/intro.md) + ## Support - [Troubleshooting](troubleshooting.md) diff --git a/book/src/access_control/intro.md b/book/src/access_control/intro.md new file mode 100644 index 000000000..323771880 --- /dev/null +++ b/book/src/access_control/intro.md @@ -0,0 +1,74 @@ +# Access Control + +While Kanidm exists to make authorisation decisions on behalf of other services, internally it must +make decisions about writes operations to the entries within its database. To make these choices, +Kanidm has an internal set of access controls which are the rules describing who may perform what +actions. + +## Default Permissions + +The project ships default access controls which are designed to limit and isolate the privileges of +accounts whenever possible. + +This separation is the reason why `admin` and `idm_admin` exist as separate accounts. There are two +distinct access silos within Kanidm. Access to manage Kanidm as a service (such as application +integrations and domain naming) and access to manage people and groups. This is to limit the +possible harm that an attacker may make if they gain access to these roles. + +## Permission Delegation + +A number of types in Kanidm allow permission delegation such as groups and service accounts. This +allows entries to be assigned an entry manager who has write access to that entity but not all +entities of the same class. + +## High Privilege Groups + +Kanidm has a special group called `idm_high_privilege`. This acts as a "taint" on its members to +indicate that they have an elevated level of access within Kanidm or other systems. + +This taint flag exists to prevent lateral movement from other roles that have higher levels of +privilege. + +An example is `idm_service_desk` which has the ability to trigger credential resets for users. This +is an important aspect of the service desk role. However, a member of the service desk should not be +able to modify the credentials of their peers, nor should they be able to escalate by accessing the +credentials of users in a role such as `idm_admins`. Since `idm_service_desk` and `idm_admins` are +both tainted with `idm_high_privilege` then this lateral movement is not possible. Only high +privileged roles are able to then reset the accounts of high privilege users. + +You may add other groups to `idm_high_privilege` to achieve the same taint effect for other +services. + +## Default Permission Groups + +Kanidm ships with default permission groups. You can use these to enable accounts to perform certain +tasks within Kanidm as required. + +| group name | description | +| ---------------------------- | ----------------------------------------------------------------------- | +| `domain_admins` | modify the name of this domain | +| `idm_access_control_admins` | write access controls | +| `idm_account_policy_admins` | modify account policy requirements for user authentication | +| `idm_group_admins` | create and modify groups | +| `idm_oauth2_admins` | create and modify oauth2 integrations | +| `idm_people_admins` | create and modify persons | +| `idm_people_on_boarding` | create (but not modify) persons. Intended for use with service accounts | +| `idm_people_pii_read` | allow read to personally identifying information | +| `idm_people_self_write_mail` | allow self-modification of the mail attribute | +| `idm_radius_servers` | read user radius secrets. Intended for use with service accounts | +| `idm_radius_service_admins` | create and reset user radius secrets, and allow users to access radius | +| `idm_recycle_bin_admins` | modify and restore entries from the recycle bin | +| `idm_schema_admins` | add and modify elements of schema | +| `idm_service_account_admins` | create and modify service accounts | +| `idm_unix_admins` | enable posix attributes on accounts and groups | + +## Default Roles + +Kanidm ships with 3 high level permission groups. These roles have no inherent permissions, they are +created by being members of the default permission groups. + +| group name | description | +| ------------------ | -------------------------------------------------------- | +| `idm_admins` | manage persons and their groups | +| `idm_service_desk` | assist persons with credential resets or other queries | +| `system_admins` | manage the operation of Kanidm as a database and service | diff --git a/book/src/accounts/anonymous.md b/book/src/accounts/anonymous.md new file mode 100644 index 000000000..0e7f5a35d --- /dev/null +++ b/book/src/accounts/anonymous.md @@ -0,0 +1,50 @@ +# Anonymous Account + +Within Kanidm there is a single "special" account. This is the anonymous service account. This +allows clients without any credentials to perform limited read actions against Kanidm. + +The anonymous account is primarily used by stateless unix clients to read account and group +information. + +## Authentication + +Even though anonymous does not have credentials it still must authenticate to establish a session to +access Kanidm. To achieve this there is a special `anonymous` credential method. Anonymous is the +only account that may use this credential method. + +## OAuth2 / OIDC + +Anonymous is a service account which prevents it from using OAuth2/OIDC to access other +applications. + +## Access + +By default anonymous has limited access to information in Kanidm. Anonymous may read the following +data. + +> NOTE: The `Name` attribute is the user's public username. This is different to their private and +> sensitive `LegalName` attribute. + +### People + +- Name +- DisplayName +- MemberOf +- Uuid +- GidNumber +- LoginShell +- SshPublicKey + +### Groups + +- Name +- Member +- DynMember +- GidNumber + +## Disabling the Anonymous Account + +The anonymous is like any other and can be expired to prevent its use. See the +[account validity section](./people#account-validity) + +When disabled, this will prevent stateless unix clients from authenticating to Kanidm. diff --git a/book/src/accounts/intro.md b/book/src/accounts/intro.md index 87ca8382d..ad9f48e01 100644 --- a/book/src/accounts/intro.md +++ b/book/src/accounts/intro.md @@ -84,39 +84,3 @@ permissions. Each group has a description to explain its purpose. These can be v kanidm group list --name idm_admin kanidm group get ``` - -## Why Can't I Change admin With idm\_admin? - -As a security mechanism there is a distinction between "accounts" and "high permission accounts". -This is to help prevent elevation attacks, where a member of a service desk could attempt to reset -the password of idm\_admin or admin, or even a member of HR or System Admin teams to move laterally. - -Generally, membership of a "privilege" group that ships with Kanidm, such as: - -- idm\_account\_manage\_priv -- idm\_people\_read\_priv -- idm\_schema\_manage\_priv -- many more ... - -...indirectly grants you membership to "idm\_high\_privilege". If you are a member of this group, -the standard "account" and "people" rights groups are NOT able to alter, read or manage these -accounts. To manage these accounts higher rights are required, such as those held by the admin -account. - -Further, groups that are considered "idm\_high\_privilege" can NOT be managed by the standard -"idm\_group\_manage\_priv" group. - -Management of high privilege accounts and groups is granted through the the "hp" variants of all -privileges. A non-conclusive list: - -- idm\_hp\_account\_read\_priv -- idm\_hp\_account\_manage\_priv -- idm\_hp\_account\_write\_priv -- idm\_hp\_group\_manage\_priv -- idm\_hp\_group\_write\_priv - -Membership of any of these groups should be considered to be equivalent to system administration -rights in the directory, and by extension, over all network resources that trust Kanidm. - -All groups that are flagged as "idm\_high\_privilege" should be audited and monitored to ensure that -they are not altered.