Repository navigation
Replies: 3 comments 2 replies
|
I don't know about a heap about the kernel keyring, and don't have much time right now but wanted to give an answer quickly now while I have a few minutes. I'm pretty sure turnstile doesn't create the dinit user-instance daemon in the login session, but then, I don't think it could (you want one dinit per user, not one per session). The problem is that kernel concept of sessions don't really correspond to user sessions; they're tied to terminals/logins, i.e. each time you login it's a new session; this doesn't match common usage where people log in multiple times on different virtual terminals.
I think this still isolates keys at the user-id level, so it's not really weakening security in any significant way, especially if you only use one session anyway. But I'm not 100% sure about this. |
|
I'm fuzzy on the dinit->turnstile->seatd (->user dinit) sequence. I'm pretty sure turstile delegates user seats to seatd, and from what I've read turstile is needed to get user dinits (dinit itself doesn't launch user dinits, right?). Yes, the per-login is a feature of session keys. Using them prevents someone with the ability to log in as you from doing so and snooping on your (legitimate) activity. Theoretically, they also protect from root snooping, since root can su to your user, but if root's compromised all bets are off so that's not much of a consideration. Protecting from e.g. hacks and worms which can log in as you is a more realistic protection: if session keys are used to store secrets, they're protected from cross-login snooping. I'd argue that common usage -- for desktop users, in any case -- is to log in once. Most people launch a desktop; even if I'm logging into a TTY, I invariably run tmux rather than switching TTYs and logging multiple times. When I remote into a server to work, it's similar: I launch tmux and work from there. I know "annecdotally" isn't worth much, but are you suggesting that you believe the common case is for users to login to any given machine multiple times? Yes: kernel user key space is per user. This means that all logins for an account can read (and write) to the same space. It means that if an account is somehow compromised, it's the key space is not safe. A use case is a key manager. If the session keyring is used, only programs run from a child of that session can read those keys. In any case, your answer confirmed what I suspected. If there's a way to launch dinit under a session, it'd be the responsibility of seatd (probably) or turnstile (maybe), and I need to ask there. Honestly, I think the answer is going to be that the only way to do this is via a session init script, like in |
|
A few belated answers:
Correct in the sense that turnstile doesn't have any knowledge of seats. You can use turnstile in conjunction with seatd, but as far as I know turnstile doesn't communicate with seatd at all.
Correct, dinit doesn't itself launch user instances of dinit. (Nor could it, really, without having something like a PAM module, which is what turnstile does).
I don't think it's a common case, but I think it's one turnstile supports.
Well, maybe. Most compromises of a single-login (i.e. desktop system) are probably going to be via things like your web browser, which is already in your session. If you have a way for worms to login then it means you've got some sort of remote login enabled, and in that case you probably do want the multiple-login "session" support that turnstile offers. So I'm not entirely convinced that a (kernel-session) session key ring is useful. (A session keyring could potentially be useful, but not one based on the kernel concept of sessions, which is tied to terminal devices; at least, that's how I see it). |
|
It's an attack surface thing. "More secure" doesn't mean "perfect", it just means "better." The user session key space closes an avenue of attack. Viruses, worms, and remote hacks would have to intentionally attack a user session by being launched by the user, instead of starting a background worker which snoops. Many of the worms we see for Linux attack system services -- root, if they can get it. Anyhoo, this is getting off topic and isn't anything dinit can do anything about. Thanks for the answer. |
Yep, I understand that. My point was about the utility trade-off. But, I'm coming at it from the perspective that I want a single user session manager instance shared between multiple logins, which is probably not your position (fair enough).
Unfortunately, yes. |
Uh oh!
There was an error while loading. Please reload this page.
The context is the kernel keyring.
I am running Artix, so dinit is running as root. Session management is via turnstiled and the user dinit is hooked in through Artix's(?) turnstile-dinit package. Everything seems to work fine, and the user dinit's being launched.
However, I have an issue in that the user dinit services are not in the same session as the X session, which means they don't share the same kernel keyring session. This means some of my secret-service software doesn't work. Because the dinit daemon is in a different session, starting a service via dinitctl from the right session doesn't help.
I have a desktop which is Arch, and so systemd; on that, I start dinit from the window manager. I could uninstall (or figure out how to disable) turnstile-dinit, as a work-around. I could also weaken my security and set my system up to use the kernel keyring user space (instead of the session). So I have work-arounds. They both feel kind of hacky (or icky, in the second case), and I'm curious if there's a better way to do this.
I suspect this may be a turnstile or seatd question, but I also suspect the answer is going to be that if I want to access the session key ring, I'm going to have to fork the user dinit from the window manager. I am asking because I'm hoping there's an answer which allows the seat manager to fork the user dinit.
All reactions