mart-w/kanidm
1
0
Fork 0
mirror of https://github.com/kanidm/kanidm.git synced 2025-02-23 20:47:01 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

continuing review of Kanidm book (#775)

Browse source
This commit is contained in:
Carla Schroder 2022-05-26 16:07:56 -07:00 committed by GitHub
parent 8abd5b2052
commit 547e283318
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 62 additions and 54 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
kanidm_book/src/client_tools.md
View file

@ -1,10 +1,12 @@
# Client tools
To interact with Kanidm as an administrator, you'll need to use our command line tools. If you haven't installed them yet, [install them now](installing_client_tools.mdc).
To interact with Kanidm as an administrator, you'll need to use our command line tools.
If you haven't installed them yet, [install them now](installing_client_tools.mdc).
## Kanidm configuration
You can configure `kanidm` to help make commands simpler by modifying `~/.config/kanidm` or `/etc/kanidm/config`.
You can configure `kanidm` to help make commands simpler by modifying `~/.config/kanidm`
or `/etc/kanidm/config`.
uri = "https://idm.example.com"
verify_ca = true|false
@ -17,13 +19,13 @@ Once configured, you can test this with:
## Session Management
To authenticate as a user for use with the command line, you need to use the `login` command
To authenticate as a user (for use with the command line), you need to use the `login` command
to establish a session token.
kanidm login --name USERNAME
kanidm login --name admin
Once complete, you can use `kanidm` without reauthenticating for a period of time for administration.
Once complete, you can use `kanidm` without re-authenticating for a period of time for administration.
You can list active sessions with:
@ -38,4 +40,3 @@ To logout of a session:
kanidm logout --name USERNAME
kanidm logout --name admin

25
kanidm_book/src/installing_client_tools.md
View file

@ -1,10 +1,13 @@
# Installing Client Tools
> **NOTE** As this project is in a rapid development phase, running different release versions will likely present incompatibilities. Ensure you're running matching release versions of client and server binaries. If you have any issues check that you are running the latest software.
> **NOTE** As this project is in a rapid development phase, running different
release versions will likely present incompatibilities. Ensure you're running
matching release versions of client and server binaries. If you have any issues,
check that you are running the latest software.
## From packages
Kanidm currently supports:
Kanidm currently supports the following Linux distributions:
* OpenSUSE Tumbleweed
* OpenSUSE Leap 15.3/15.4
@ -13,7 +16,7 @@ Kanidm currently supports:
### OpenSUSE Tumbleweed
Kanidm is part of OpenSUSE Tumbleweed since October 2020. This means you can install
Kanidm has been part of OpenSUSE Tumbleweed since October 2020. You can install
the clients with:
zypper ref
@ -21,7 +24,7 @@ the clients with:
### OpenSUSE Leap 15.3/15.4
Leap 15.3/15.4 is still not fully supported with Kanidm. For an experimental client, you can
Leap 15.3/15.4 does not have full Kanidm support. For an experimental client, you can
try the development repository. Using zypper you can add the repository with:
zypper ar -f obs://network:idm network_idm
@ -33,19 +36,20 @@ Then you need to refresh your metadata and install the clients.
### Fedora / Centos Stream
Fedora has limited support through the development repository. You need to add the repository metadata into the correct directory.
Fedora has limited support through the development repository. You need to add the repository
metadata into the correct directory:
cd /etc/yum.repos.d
# Fedora 34
sudo wget https://download.opensuse.org/repositories/network:/idm/Fedora_34/network:idm.repo
wget https://download.opensuse.org/repositories/network:/idm/Fedora_34/network:idm.repo
# Fedora 35
sudo wget https://download.opensuse.org/repositories/network:/idm/Fedora_35/network:idm.repo
wget https://download.opensuse.org/repositories/network:/idm/Fedora_35/network:idm.repo
# Centos Stream 9
sudo wget https://download.opensuse.org/repositories/network:/idm/CentOS_9_Stream/network:idm.repo
wget https://download.opensuse.org/repositories/network:/idm/CentOS_9_Stream/network:idm.repo
You can then install with:
sudo dnf install kanidm-clients
dnf install kanidm-clients
## From source (CLI only, not recommended)
@ -63,4 +67,5 @@ with the -C parameter:
kanidm self whoami -C ../path/to/ca.pem -H https://localhost:8443 --name anonymous
kanidm self whoami -H https://localhost:8443 --name anonymous
Now you can take some time to look at what commands are available - please [ask for help at any time](https://github.com/kanidm/kanidm#getting-in-contact--questions).
Now you can take some time to look at what commands are available - please
[ask for help at any time](https://github.com/kanidm/kanidm#getting-in-contact--questions).

74
kanidm_book/src/security_hardening.md
View file

@ -9,11 +9,11 @@ follow to ensure that Kanidm operates in a secure environment.
The main server is a high-value target for a potential attack, as Kanidm serves as
the authority on identity and authorisation in a network. Compromise of the Kanidm
server is equivalent to a full-network take over, AKA "game over".
server is equivalent to a full-network take over, also known as "game over".
The unixd resolver is also a high value target as it can be accessed to allow unauthorised
access to a server, to intercept communications to the server, or more. This also must be protected
carfully.
carefully.
For this reason, Kanidm's components must be protected carefully. Kanidm avoids many classic
attacks by being developed in a memory safe language, but risks still exist.
@ -37,28 +37,28 @@ Each warning highlights an issue that may exist in your environment. It is not p
prescribe an exact configuration that may secure your system. This is why we only present
possible risks.
### Should be readonly to running uid
### Should be Read-only to Running UID
Files such as configurations should be readonly to this UID/GID. This is so that if an attacker is
able to gain code execution, they are unable to modify the configuration to write or over-write
Files, such as configuration files, should be read-only to the UID of the Kanidm daemon. If an attacker is
able to gain code execution, they are then unable to modify the configuration to write, or to over-write
files in other locations, or to tamper with the systems configuration.
This can be prevented by changing the files ownership to another user, or removing "write" bits
from the group.
### 'everyone' permission bits in the mode
### 'everyone' Permission Bits in the Mode
This means that given a permission mask, "everyone" or all users of the system can read, write or
execute the content of this file. This may mean that if an account on the system is compromised the
attacker can read Kanidm content and may be able to further attack the system as a result.
This can be prevented by removed everyone execute bits from parent directories containing the
configuration, and removing everyone bits from the files in question.
This can be prevented by removing "everyone: execute bits from parent directories containing the
configuration, and removing "everyone" bits from the files in question.
### owned by the current uid, which may allow file permission changes
### Owned by the Current UID, Which May Allow File Permission Changes
File permissions in unix systems are a discrestionary access control system, which means the
named uid owner is able to further modify the access of a file regardless of the current
File permissions in UNIX systems are a discretionary access control system, which means the
named UID owner is able to further modify the access of a file regardless of the current
settings. For example:
[william@amethyst 12:25] /tmp > touch test
@ -72,21 +72,21 @@ settings. For example:
-rw-r--r-- 1 william wheel 0 29 Jul 12:25 test
Notice that even though the file was set to "read only" to william, and no permission to any
other users, that as "william" I can change the bits to add write permissions back or permissions
other users, user "william" can change the bits to add write permissions back or permissions
for other users.
This can be prevent by making the file owner a different UID to the running process for kanidm.
This can be prevent by making the file owner a different UID than the running process for kanidm.
### A secure example
### A Secure Example
Between these three issues it can be hard to see a possible strategy to secure files, however
one way exists - group read permissions. The most effective method to secure resources for kanidm
one way exists - group read permissions. The most effective method to secure resources for Kanidm
is to set configurations to:
[william@amethyst 12:26] /etc/kanidm > ls -al server.toml
-r--r----- 1 root kanidm 212 28 Jul 16:53 server.toml
The kanidm server should be run as "kanidm:kanidm" with the appropriate user and user private
The Kanidm server should be run as "kanidm:kanidm" with the appropriate user and user private
group created on your system. This applies to unixd configuration as well.
For the database your data folder should be:
@ -96,51 +96,53 @@ For the database your data folder should be:
drwxrwx--- 3 root kanidm 96 29 Jul 12:38 .
-rw-r----- 1 kanidm kanidm 544768 29 Jul 12:38 kanidm.db
IE this means 770 root:kanidm. This allows kanidm to create new files in the folder, but prevents
kanidm being able to change the permissions of the folder. Because the folder does not have
everyone mode bits, the content of the database is secure because users can now cd/read
This means 770 root:kanidm. This allows Kanidm to create new files in the folder, but prevents
Kanidm from being able to change the permissions of the folder. Because the folder does not have
"everyone" mode bits, the content of the database is secure because users can now cd/read
from the directory.
Configurations for clients such as /etc/kanidm/config should be secured with the permissions
as:
Configurations for clients, such as /etc/kanidm/config, should be secured with read-only permissions
and owned by root:
[william@amethyst 12:26] /etc/kanidm > ls -al config
-r--r--r-- 1 root wheel 38 10 Jul 10:10 config
-r--r--r-- 1 root root 38 10 Jul 10:10 config
This file should be everyone-readable which is why the bits are defined as such.
This file should be "everyone"-readable, which is why the bits are defined as such.
> NOTE: Why do you use 440 or 444 modes?
>
> A bug exists in the implementation of readonly() in rust that checks this as "does a write
> bit exist for any user" vs "can the current uid write the file?". This distinction is subtle
> but it affects the check. We don't believe this is a significant issue though because
> bit exist for any user" vs "can the current UID write the file?". This distinction is subtle
> but it affects the check. We don't believe this is a significant issue though, because
> setting these to 440 and 444 helps to prevent accidental changes by an administrator anyway
## Running as non-root in docker
## Running as Non-root in docker
The commands provided in this book will run kanidmd as "root" in the container to make the onboarding
smoother. However, this is not recommended in production for security reasons.
You should allocate a uidnumber/gidnumber for the service to run as that is unique on your host
You should allocate unique UID and GID numbers for the service to run as on your host
system. In this example we use `1000:1000`
You will need to adjust the permissions on the `/data` volume to ensure that the process
can manage the files. Kanidm requires the ability to write to the `/data` directory to create
the sqlite files. This uid/gidnumber should match the above. You could consider the following
the sqlite files. This UID/GID number should match the above. You could consider the following
changes to help isolate these changes:
docker run --rm -i -t -v kanidmd:/data opensuse/leap:latest /bin/sh
# mkdir /data/db/
# chown 1000:1000 /data/db/
# chmod 750 /data/db/
# sed -i -e "s/db_path.*/db_path = \"\/data\/db\/kanidm.db\"/g" /data/server.toml
# chown root:root /data/server.toml
# chmod 644 /data/server.toml
mkdir /data/db/
chown 1000:1000 /data/db/
chmod 750 /data/db/
sed -i -e "s/db_path.*/db_path = \"\/data\/db\/kanidm.db\"/g" /data/server.toml
chown root:root /data/server.toml
chmod 644 /data/server.toml
You can then use this with run the kanidm server in docker with a user.
Note that the example commands all run inside the docker container.
You can then use this to run the Kanidm server in docker with a user:
docker run --rm -i -t -u 1000:1000 -v kanidmd:/data kanidm/server:latest /sbin/kanidmd ...
> **HINT**
> You need to use the uidnumber/gidnumber to the `-u` argument, as the container can't resolve
> You need to use the UID or GID number with the `-u` argument, as the container can't resolve
> usernames from the host system.