-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NixOS, Home-Manager, and Kanidm Unixd #2698
Comments
This seems less like an issue, and more like some braindumps about things.
|
Perhaps - it wasn't my intention. I believe it does concern Kanidm in some way (if not exactly via features, at least via intended usage). At the very least I wanted to get an idea of the Kanidm teams' thoughts when it comes to the concept behind what I'm trying to achieve.
I don't mean for the whole
I am still interested about machine-specific groups - is the idea that Kanidm is used for all groups (including system-specific ones like
Correct me if I'm wrong, but I gather this refers to changes on the Kanidm side in order to expose this functionality, not something that is already possible with the current release candidate |
One other alternative that I hadn't thought of - it looks like it's possible to use the kanidm UUID in places like e.g. |
Yes, we resolve anything that uniquely identifies the account, even if we only present the spn/name. |
The issue I opened hasn't been addressed, so it looks like my only option is to make the changes to home-manager/nixos myself. In any case, I haven't been able to find anything about managing local groups (except for a vague mention which I suspect is related to the ability to override local groups - I'm not familiar enough with rust to figure that out myself), what is the intended solution here? To give a concrete example: say I have a client with hyprland, which uses Given this situation, how do you grant access to a user authenticating through
|
Being in the local You could enable allow_local_account_override, create a There's no simple answer as you're messing around with local device/hardware permissions. |
Granted all this, I have a few questions:
In conclusion, what's the best way forward? If it means modifying my systems' config so that permissions are looser I'm open to that, but I generally prefer a platform agnostic approach - something that will work in almost all cases, even for programs that aren't designed with this in mind. In fact, it may improve UX to boil things down a little and make heavy use of the mapping terminology, rather than the current somewhat fragmented CLI syntax. But I digress. If this is an issue that requires a solution from the kanidm side of things, I have a couple of ideas that may (hopefully) help with a useful/usable implementation |
If you override something from the kanidm side, since users can rename themself they could rename themself to be that account. Imagine you allowed a local override for "root", but never created a root account in kanidm. I could then rename myself to be root and ssh in. Similar for other groups and users, it can allow lateral movement and priv esc. So if you enable a local override, it's because you have to guarantee that the user or group in the override won't actually be deleted or changed in a way that could allow someone to perform this attack. The other issue is that if you overrired something in kani with different uid/gidnumbers, then you can have some oddities occur which can confuse the local system if the kanidm-unixd resolver isn't able to server that id for some reason. Imagine if the local account "test" was uidnumber 1000 but kanidm has it as uidnumber 2000. Depending on who/when it's resolved, it'll have different ID's. Another example here is imagine you use both debian and redhat. They may have the same group like wheel, but it has different uid/gidnumbers. So you can't reflect this group into kanidm without negatively affecting the other. Generally though, it's just messy because you don't have a clear deliniation between "this is the system" and "this is kanidm". You end up with an ID that has joint ownership of the details and it can get messy. |
You can easily stomp whatever's configured for local groups/users.
I honestly can't understand what you're saying here, you might need to explain in a different way, or give examples. |
ANother example is systemd users - which is a genuinely good feature of systemd for packages, but it doesn't guarantee that every system will get the same uid/gid for that username, so more opportunities to stomp. System users are owned by the system, kani users are owned by kani, and unless you have some absolutely unhinged wild use case that can't avoid this, then they should always be separate. |
Good points all around. So the best course of action is probably to figure out how to fix the permissions elsewhere such that a kani user doesn't have to be part of the group...? |
Perhaps a better question: taking a step back, is authentication on a "regular" computer something kanidm should support? I'm inclined to believe yes (due to the TPM/fingerprint functionality etc), but I could be wrong |
Well yes. But there is a difference between adding a kanidm account as a member to a system group, and overridding a system user or group with one from Kanidm. One has a clear separation. The system group can happliy accept a kanidm user as a member. But the latter, when you stomp a system group with a kanidm provided group is a recipe for chaos. |
Ah. I was not aware this was possible. This should solve things for me at the moment, but does still pose a scaling question, as each user still needs to be added individually, rather than being able to reference a group from kanidm |
Well that might be possible to have a way to extend an existing system group with extra members, but I need to think more about it. |
Is your feature request related to a problem? Please describe.
Using
kanidm-unixd
on NixOS is generally pretty great, but there are a couple gaps that I believe require some changes/information from Kanidm. These are primarily:Describe the solution you'd like
Exposing a UUID
Exposing a UUID should solve the following:
systemd-homed
(I believe?) tok-unixd
client, if the dataset doesn't existzroot/home/UUID
to/home/current-username
is perfect for this, since the mount only survives as long as the user's session, which should be fine in about 99% of the time. NixOS already has a module that integratessystemd-homed
andzfs
together, so the main difference is mapping the Kanidm UUID in there.I am aware that it is possible to get a users' UUID via API requests or such, but (whether it exists already or not) I would like to be able to (if possible) transparently query through PAM (for improved compatibility with e.g. home-manager/sytemd-homed), or the
kanidm-unixd
daemon, so it can continue to work offline. I'm unsure as to how exactly this would function, I'm not super familiar with PAM etc.The issue with
systemd-homed
should be pretty self explanatory - I need a method to get a users' UUID in order to create the dataset, as well as a method to get the username currently correlated to said UUID at mount time. I have yet to track down how exactly this functions in a "typical" scenario (with local users/groups), I'll update when that happens.The issue with home-manager is a little more complex. To avoid going too far into detail with the specifics of home-manager, it basically boils down to three main points where HM interacts with UUIDs:
/etc/nix-profile
/etc/nix-profile
, and activates said configuration (places symlinks in their home directory)The first point is most likely just a case of "Use the UUID instead of the username", thus not really concerning Kanidm. This should also pave the way for the next two steps.
Step two should be solved by step one using UUIDs; each is Unique and immutable.
Step three is the main issue - while I have yet to track down the exact source code, HM needs to be able to activate the profile prepared in
/etc/nix-profile/hm-uuid-or-username
, which is typically handled by grabbing the uuid/username from said profile, and adding it to/home/
(or whatever the user has set as the home prefix). There needs to be a way for HM to query Kanidm for the current username the UUID refers to, so it can select the correct/home/
directory aftersystemd-homed
does it's mounting.As an alternative, it is technically possible to just set the SPN field in Kanidm to the UUID directly, avoiding many of the issues - but that messes with how permissions are resolved in graphical applications like the file manager - viewing permissions on a network share would show a UUID instead of a username, which is arguably unusable and could result in nasty consequences.
One other solution I thought of was to mount the users' home directory twice; once via username and once via UUID. This would allow HM to keep its' default behavior of concatenation, but again could very well introduce some other unwanted side effects.
Separation of state
Kanidm, by it's own definition, is meant to be the source of truth. Mixed in with that, however, are some other less clear examples of "state" which could technically be managed by Kanidm, but in actuality shouldn't be. I've split the relevant details I have so far into three groups based on what I think the separation should look like, but feel free to make changes or tweaks.
Kanidm State
Device-local (maybe TPM?) state
kanidm-unixd
, and only valid on that specific device - again, probably backed by the TPM)Unsure
networkmanager
,wireshark
,adb
etc)I'm starting to run out of capacity to think now, so I'll add revisions via comments later on should I think of anything else to add.
For reference:
#1747
#2251 (comment)
https://nix-community.github.io/home-manager/index.xhtml#sec-install-nixos-module
https://nix-community.github.io/home-manager/index.xhtml#_how_to_set_up_a_configuration_for_multiple_users_machines
https://nix-community.github.io/home-manager/nixos-options.xhtml#nixos-opt-home-manager.useUserPackages
The text was updated successfully, but these errors were encountered: