Add security overview doc #1099
Conversation
bdf390b to
5fb86f6
Compare
|
I decided to not document how we protect communication between authd components for now, because that would be a pretty long section and require explaining the architecture in more detail than it's currently explained on https://documentation.ubuntu.com/authd/stable-docs/explanation/authd-architecture/ (that's missing the authd PAM Go binary which communicates with the PAM module via a private D-Bus server). I'll need more time for that than I planned for this issue for now (and if we do create that section, we might also want to update the architecture page). |
cfb7c61 to
cd246c4
Compare
|
@edibotopic I'm sure there are many things to improve here. Feel free to make changes as you see fit. |
|
Will do @adombeck . Updating the arch section, as you mention, is a good idea, but it can wait until the next cycle. |
There was a problem hiding this comment.
Excellent work @adombeck .
This is a very comprehensive overview and links well with the rest of the documentation.
Mostly minor suggestions from me, but the overall content and structure looks good.
f89f720 to
4010159
Compare
|
@edibotopic Thanks for the excellent review! I think addressed all your comments now. |
4010159 to
44ea7ee
Compare
Co-authored-by: Shane Crowley <[email protected]>
44ea7ee to
ed4eaae
Compare
| existing users or groups on the system. However, if a user or group is later | ||
| removed, or if the entire authd database (`/var/lib/authd/authd.sqlite3`) is |
There was a problem hiding this comment.
@adombeck maybe we should add a card to keep the removed users as disabled users forever, so that those UIDs/GIDs are never re-used as they may imply that another user (created at later point) could access to files owned by the old one.
There was a problem hiding this comment.
I think we should provide a way to actually free up previously used UIDs/GIDs. The situation is not different from deluser which also removes the UID and allows it to be reused by new user accounts - except that authd automatically creates new user accounts, which is one way UIDs could be reused.
We already had discussions around that, which resulted in the updated description of #640. The plan is to warn the user about UID/GID reuse when they try to delete a user/group and ask for confirmation.
There was a problem hiding this comment.
If you want to check some previous literature on this:
- https://salsa.debian.org/gnome-team/gdm/-/commit/ade174bfe73b81ac80b4a707f7be241304846429
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006912
In general cleaning up old IDs isn't a big deal as we should have enough available values anyways.
First draft of a security overview for authd. See the Jira ticket for context.
UDENG-7652
TODO
Protection of communication between authd componentssee Add security overview doc #1099 (comment)Link to the SSH section of the security overview in the "Log in with SSH" pageWill be done in a follow-up, tracked in https://warthogs.atlassian.net/browse/UDENG-8258