aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTed Gould <ted@gould.cx>2013-06-25 16:10:40 -0500
committerTed Gould <ted@gould.cx>2013-06-25 16:10:40 -0500
commit74c8cdb04beefde5fdfa25398f8741d5865effff (patch)
tree77564575a2065ac5e4a343fae5d35660502fd277
downloadayatana-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--README66
1 files changed, 66 insertions, 0 deletions
diff --git a/README b/README
new file mode 100644
index 0000000..ee83e78
--- /dev/null
+++ b/README
@@ -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.
+