diff options
| author | Ted Gould <ted@gould.cx> | 2013-06-25 16:10:40 -0500 |
|---|---|---|
| committer | Ted Gould <ted@gould.cx> | 2013-06-25 16:10:40 -0500 |
| commit | 74c8cdb04beefde5fdfa25398f8741d5865effff (patch) | |
| tree | 77564575a2065ac5e4a343fae5d35660502fd277 | |
| download | ayatana-greeter-session-broadcast-74c8cdb04beefde5fdfa25398f8741d5865effff.tar.gz ayatana-greeter-session-broadcast-74c8cdb04beefde5fdfa25398f8741d5865effff.tar.bz2 ayatana-greeter-session-broadcast-74c8cdb04beefde5fdfa25398f8741d5865effff.zip | |
Let's talk about what we're creating
| -rw-r--r-- | README | 66 |
1 files changed, 66 insertions, 0 deletions
@@ -0,0 +1,66 @@ +Introduction +------------ + +The session broadcast service exists to provide a way for the greeter +to be able to communicate back to the user session information about +the user's desires without having to connect to the session and provide +access to all that it would contain. This is because the greeter is +untrusted in a multi-user system, and thus shouldn't connect to the user's +session. While this does allow more access than most multi-user systems +would allos, it is designed for cases of single user systems that have +multi-user for security and thus is about limiting the interaction +more than providing complete security around the session. + +How it works +------------ + +The greeter session can send a message to a service that exists on the system +DBus. That messages is then rebroadcast as a signal coming from the well-known +name of the system service. Each user session that is currently active has a +listener for that well known signal and acts on it taking into account the current +settings of the session. + + + Greeter Session User Session + +----------------------------------+ +------------------------------------+ + | | | | + | | | | + | +--------------------+ | | +-------------------+ | + | | | | | | | | + | | | | | | | | + | | Greeter | | | | User Agent | | + | | | | | | | | + | | | | | | | | + | +--------------------+ | | +-------------------+ | + | + | | + | + | | | | | | + | | | | | | + +-----------------------------|----+ +-----------|------------------------+ + |Sends message | Listens for Signal + | | + +------------------|----------------------------|---------+ + | | v | + | System Bus | ^ | + +------------------|-------------------|------------------+ + v + Emits Signal + +-----------------------------+ + | | + | Session Broadcast | + | | + +-----------------------------+ + +Security +-------- + +As noted in the introduction we're not creating something that is completely +secure, but that doesn't mean we can't take some measures to ensure that security +isn't forgotten. So the following policies are in place: + + * Messages are only accepted from the lightdm user. All other messages from + other folks on the bus are rejected. + * The User session will have a configuration option to whether the events will + be acted on. This allows for configuring user sessions to be more secure if + needed for particular uses (enterprise, government, etc.) + * Each message and feature will be well defined without dictionaries or other + extension mechanisms. + |