Comments (16)
This seems less like an issue, and more like some braindumps about things.
- I don't want to integrate with systemd-homed
- If we were to mount arbitrary filesystems or create them on login, then that would be part of kanidm-unixd-tasks, which already exists
- For authentication with TPM, we have plans for this already.
- Local querying of user detais would be possible with some pretty basic extensions to the unix socket api.
from kanidm.
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 want to integrate with systemd-homed
I don't mean for the whole homectl
thing, if that's what you're referring to - I merely meant that there is an existing implementation that (as far as I'm aware) uses systemd-homed
under the hood to accomplish creation/mounting/encryption of home directories on login (which, as you said, might end up being part of kanidm-unixd-tasks
- I believe creating home directories and the relevant symlinks is already handled by it).
So if you would prefer to implement this directly rather than me creating a third-party configuration which leverages systemd-homed
, consider it a feature request.
For authentication with TPM, we have plans for this already.
I am still interested about machine-specific groups - is the idea that Kanidm is used for all groups (including system-specific ones like networkmanager
etc), or is kanidm-unixd
intended to be primarily an extension that provides user authentication alongside preexisting groups?
Local querying of user detais would be possible with some pretty basic extensions to the unix socket api.
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
from kanidm.
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. chown uuid:uuid test.txt
while still having the uid_attr_map
set to spn
- it might be possible to leverage that in the cases above.
from kanidm.
Yes, we resolve anything that uniquely identifies the account, even if we only present the spn/name.
from kanidm.
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 brillo
to let unpriviledged users control the screen brightness. Brillo requires the user to be in the video
group to control brightness, which for the sake of argument cannot be configured (even if brillo can be configured differently, I'm fairly certain there are other programs which are less flexible).
Given this situation, how do you grant access to a user authenticating through kanidm_unixd
:
- Enable
allow_local_account_override
- This can "...have many unexpected consequences" (I presume this refers to a situation where a local user is part of a group, and pam queries kanidm asking if the local user is part of said group, to which kanidm responds with "no, this user doesn't even exist in kanidm"?)
- This is also an issue if you have multiple machines, since there can only ever be one
video
group in Kanidm, and overrides only work on a name collision basis - as far as I know it would then be impossible for a specific user to be part of thevideo
group on one client but not another; something more advanced like an "override map" would be needed, which could function similar to an OIDC claim map
- Add the remote user to the local group via
/etc/group
- As far as I know this would just end up being a massive pain (not to mention a second source of truth), since you can't just add a Kanidm group as a member of the local group (like you can with Kanidm to inherit group membership) - you would have to add each user individually
- Change the group the program expects
- This isn't always possible, and while in a perfect world one would just modify the program directly, that isn't always possible or realistic.
- This also breaks the stateless nature of
kanidm-unixd
, which is quite handy in many cases (especially in NixOS)
from kanidm.
Being in the local video
group is likely nothing to do with Brillo's settings and more about the permissions that group enables - ref Debian's system group list since I couldn't find a nixOS one - but video's pretty standard across most distro's as a "used locally to give a set of users access to a video device (like a webcam)."
You could enable allow_local_account_override, create a video
group in Kanidm and add users to that, but yes, it's not limited per-machine. That's the problem with using system-local groups as the source of permissions 🤷🏻
There's no simple answer as you're messing around with local device/hardware permissions.
from kanidm.
Granted all this, I have a few questions:
- What are the actual pitfalls of enabling local overrides? I don't believe its mentioned anywhere.
- This sort of situation seems like it should be supported - despite the general design of posix groups leaning more towards the headless server side of things (what with ssh etc), the docs mention things like logging into your laptop while out in the park without internet (in reference to clearing the kanidm unixd cache iirc), which seems to imply that you should be able to use a "regular" laptop normally. I personally consider things like wifi/brightness/sound/webcam to be part of the typical use case.
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.
I realise that its a fine balance between secure design and compatibility, but I really do wonder if a mapping would work well here. Mappings seem to be a great system for keeping Kanidm simple but powerful - the core idea of kanidm's user/group schema is simple to pick up, and mappings isolates issues with compatibility and security to a single "protocol". This in turn means that changes can be made on a case by case basis, without having a ripple effect on the entire system.
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
from kanidm.
What are the actual pitfalls of enabling local overrides? I don't believe its mentioned anywhere.
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.
from kanidm.
- What are the actual pitfalls of enabling local overrides? I don't believe its mentioned anywhere.
You can easily stomp whatever's configured for local groups/users.
a mapping would work well here. Mappings seem to be a great system for keeping Kanidm simple but powerful - the core idea of kanidm's user/group schema is simple to pick up, and mappings isolates issues with compatibility and security to a single "protocol". This in turn means that changes can be made on a case by case basis, without having a ripple effect on the entire system.
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.
I honestly can't understand what you're saying here, you might need to explain in a different way, or give examples.
from kanidm.
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.
from kanidm.
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...?
from kanidm.
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
from kanidm.
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.
from kanidm.
The system group can happliy accept a kanidm user as a member
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
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.
from kanidm.
Just a couple of thoughts for extending groups:
- Something that is functionally similar to an OIDC claim map would be fine with me
- I think it would make sense to define the mapping (i.e. which local groups get mapped) locally in the
kanidm-unixd
config by group name; then UID/GID information can be handled dynamically on a per-system basis (i.e. RHEL vs Debian) - I'm not familiar with how PAM queries work in terms of group membership, but from what I've seen so far it's in order of priority - pam queries whichever provider is listed first, and continues in order. I think it makes sense for kanidm-unixd to be towards the end, which should allow kanidm-unixd to extend groups properly (as local groups would always come first)
from kanidm.
Related Issues (20)
- Can't login to instance due to token serialisation issue HOT 3
- Logout fails with "unable to access token public key"
- build: Add feature switches for conditional vendoring of dependencies HOT 1
- kanidm cli logs on debug level HOT 2
- Comparing Kanidm with other services HOT 2
- Package binaries for AUR HOT 1
- Building clients from AUR fails on orca compilation HOT 7
- New person accounts not being added to dynamic groups HOT 12
- Horizontal scroll bar missing from otp url box, causing potential miss copy/paste
- Can't sign out properly HOT 9
- Allow bindaddress to be a unix socket HOT 1
- Option to disable self managing displayname, name, and legal name
- forward_auth support in kanidm HOT 16
- oauth2 authorization code can be exchanged for access token multiple times HOT 2
- OAuth2 Debugging Tools
- migrate_domain_6_to_7: MG0005GidConstraintsNotMet HOT 2
- Issue upgrading from v1.1.0-beta.13 (1.1.0~beta13~git7.1fb34a9) -> 1.2.1 HOT 3
- The "Install" link on the homepage (top) is broken HOT 1
- Support OIDC client_ids of OwnCloud Desktop, Android, iOS HOT 14
- Support the change-password URI spec with a redirect HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kanidm.