<div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 20, 2012 at 10:53 AM, James Hunt <<a href="mailto:james.hunt@ubuntu.com" target="_blank">james.hunt@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Evan, <div class="im"> On 20/11/12 13:58, Evan Huus wrote: > Hi James, > > I've only scanned it briefly at this point, but I have one question regarding > security. At the moment the spec. states that system events will by default be > available to user sessions as well, but I think this is overly permissive. While > I can't actually think of a current system event that really must be hidden, I > feel that on principle system events should not be visible to user sessions > unless explicitly marked as such. > > I would suggest a change to the new event syntax such that > > - foo and ::foo are always equivalent, and emit an event only visible within the > current upstart namespace (system or user) > - :sys:foo and :user:foo are unchanged > - :all:foo (or :global:foo or :public:foo) emits an event visible to other > upstart namespaces as well </div>This would mean user jobs would not be able to react to system job events. That in itself might not be a problem [1], but it would also mean that user jobs have no access to system events (by default) that don't relate to jobs. I think this _is_ potentially more of an issue. My canonical example is being able to plug a USB headset in, and have a user job react to the udev event and start an application of my choice. This currently works if user jobs are enabled in Ubuntu and is a useful feature. If we did implement ':all:', we could change the upstart-udev-bridge to ensure it emits events to ':all:', but we're then back to the concern over permissiveness and it feels wrong to special-case one particular event source. </blockquote><div> I don't think this is a bad solution - users need access to device events (and effectively already have them anyways) so it makes sense for upstart-udev-bridge to emit public events. It's just a question whether it does so explicitly or implicitly. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> So, if we do 'hide' system events from user jobs by default, we would be breaking the current publish-subscribe behaviour. That's not to say we won't consider doing this [2], but we are striving to retain current behaviour so I'd like to understand better what the potential 'attack vector' might be with some real world examples. I think this needs to be explored further. Can anyone think of scenarios where user jobs should not be privy to system events? </blockquote><div> The case that originally came to mind was some sort of system audit or scan. If my system does an anti-virus scan, I don't want potential userspace malware to receive a nice convenient event notification that they should quiesce until the scan is finished (and then another notification to wake back up again once the scan completes). </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Note that Upstart is happy to run system jobs whose configuration files have perms 0400 and the /var/log/upstart/* files are not readable by normal users, so AFAICS, the risk is probably limited to users being able to 'sniff' system event environment variables. This is only a problem if an admin creates a job where they specify sensitive information in one of those variables. However, I have personally never seen such a job and is kind of analogous to an admin doing something inappropriate such as 'sudo chmod 777 /etc/shadow'. </blockquote><div> This feels kind of hacky, but perhaps we should only publish system job events to users that have read access on the job file in question? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> > > Thoughts? > > Cheers, > Evan > > > On Tue, Nov 20, 2012 at 5:09 AM, James Hunt <<a href="mailto:james.hunt@ubuntu.com">james.hunt@ubuntu.com</a> </div><div><div class="h5">> <mailto:<a href="mailto:james.hunt@ubuntu.com">james.hunt@ubuntu.com</a>>> wrote: > > Here is the draft plan for 'Enhanced Upstart User Sessions' ([1]), which will be > used to supervise desktop sessions in Ubuntu: > > <a href="https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions" target="_blank">https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions</a> > > = Summary = > > Allow Upstart to run as a non-privileged user to supervise a session in an > event-based manner. > > This brings many advantages including: > > - more dynamic and efficient session startup (desktop services only get started > *when required*). > - reliable session shutdown. > - automatic job output logging. > - more efficient use of system resources (helping to maximise battery life for > example). > > Comments Welcome. If you would like to get involved in this project, please let > me know. > > Kind regards, > > James. > > [1] - > <a href="https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upstart-user-session-enhancements" target="_blank">https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upstart-user-session-enhancements</a> > -- > James Hunt > ____________________________________ > <a href="http://upstart.ubuntu.com/cookbook" target="_blank">http://upstart.ubuntu.com/cookbook</a> > <a href="http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf" target="_blank">http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf</a> > > -- > upstart-devel mailing list </div></div>> <a href="mailto:upstart-devel@lists.ubuntu.com">upstart-devel@lists.ubuntu.com</a> <mailto:<a href="mailto:upstart-devel@lists.ubuntu.com">upstart-devel@lists.ubuntu.com</a>> <div class="im">> Modify settings or unsubscribe at: > <a href="https://lists.ubuntu.com/mailman/listinfo/upstart-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/upstart-devel</a> > > </div>Kind regards, James. [1] - Its unclear what use-cases there are for user jobs reacting to system _jobs_, so if you have some, please let us know. To lend weight to this, there is also the issue that even if user jobs can access system job events, they can only see those events that occur after their Session Init has started. See section 'Outstanding Issues' in the spec and bug 1065965. </blockquote><div> I don't have any use cases for user jobs reacting to system jobs which is why I figured they don't need to be exposed. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> [2] - Since I don't think user jobs are widely used, and are in fact currently disabled in Ubuntu. </blockquote><div> I certainly have never bothered to set them up. </div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Nov 20, 2012 at 10:53 AM, James Hunt <<a href="mailto:james.hunt@ubuntu.com" target="_blank">james.hunt@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Evan, <div class="im"> On 20/11/12 13:58, Evan Huus wrote: > Hi James, > > I've only scanned it briefly at this point, but I have one question regarding > security. At the moment the spec. states that system events will by default be > available to user sessions as well, but I think this is overly permissive. While > I can't actually think of a current system event that really must be hidden, I > feel that on principle system events should not be visible to user sessions > unless explicitly marked as such. > > I would suggest a change to the new event syntax such that > > - foo and ::foo are always equivalent, and emit an event only visible within the > current upstart namespace (system or user) > - :sys:foo and :user:foo are unchanged > - :all:foo (or :global:foo or :public:foo) emits an event visible to other > upstart namespaces as well </div>This would mean user jobs would not be able to react to system job events. That in itself might not be a problem [1], but it would also mean that user jobs have no access to system events (by default) that don't relate to jobs. I think this _is_ potentially more of an issue. My canonical example is being able to plug a USB headset in, and have a user job react to the udev event and start an application of my choice. This currently works if user jobs are enabled in Ubuntu and is a useful feature. If we did implement ':all:', we could change the upstart-udev-bridge to ensure it emits events to ':all:', but we're then back to the concern over permissiveness and it feels wrong to special-case one particular event source. So, if we do 'hide' system events from user jobs by default, we would be breaking the current publish-subscribe behaviour. That's not to say we won't consider doing this [2], but we are striving to retain current behaviour so I'd like to understand better what the potential 'attack vector' might be with some real world examples. I think this needs to be explored further. Can anyone think of scenarios where user jobs should not be privy to system events? Note that Upstart is happy to run system jobs whose configuration files have perms 0400 and the /var/log/upstart/* files are not readable by normal users, so AFAICS, the risk is probably limited to users being able to 'sniff' system event environment variables. This is only a problem if an admin creates a job where they specify sensitive information in one of those variables. However, I have personally never seen such a job and is kind of analogous to an admin doing something inappropriate such as 'sudo chmod 777 /etc/shadow'. <div class="im"> > > Thoughts? > > Cheers, > Evan > > > On Tue, Nov 20, 2012 at 5:09 AM, James Hunt <<a href="mailto:james.hunt@ubuntu.com">james.hunt@ubuntu.com</a> </div><div><div class="h5">> <mailto:<a href="mailto:james.hunt@ubuntu.com">james.hunt@ubuntu.com</a>>> wrote: > > Here is the draft plan for 'Enhanced Upstart User Sessions' ([1]), which will be > used to supervise desktop sessions in Ubuntu: > > <a href="https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions" target="_blank">https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions</a> > > = Summary = > > Allow Upstart to run as a non-privileged user to supervise a session in an > event-based manner. > > This brings many advantages including: > > - more dynamic and efficient session startup (desktop services only get started > *when required*). > - reliable session shutdown. > - automatic job output logging. > - more efficient use of system resources (helping to maximise battery life for > example). > > Comments Welcome. If you would like to get involved in this project, please let > me know. > > Kind regards, > > James. > > [1] - > <a href="https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upstart-user-session-enhancements" target="_blank">https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upstart-user-session-enhancements</a> > -- > James Hunt > ____________________________________ > <a href="http://upstart.ubuntu.com/cookbook" target="_blank">http://upstart.ubuntu.com/cookbook</a> > <a href="http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf" target="_blank">http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf</a> > > -- > upstart-devel mailing list </div></div>> <a href="mailto:upstart-devel@lists.ubuntu.com">upstart-devel@lists.ubuntu.com</a> <mailto:<a href="mailto:upstart-devel@lists.ubuntu.com">upstart-devel@lists.ubuntu.com</a>> <div class="im">> Modify settings or unsubscribe at: > <a href="https://lists.ubuntu.com/mailman/listinfo/upstart-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/upstart-devel</a> > > </div>Kind regards, James. [1] - Its unclear what use-cases there are for user jobs reacting to system _jobs_, so if you have some, please let us know. To lend weight to this, there is also the issue that even if user jobs can access system job events, they can only see those events that occur after their Session Init has started. See section 'Outstanding Issues' in the spec and bug 1065965. [2] - Since I don't think user jobs are widely used, and are in fact currently disabled in Ubuntu. <div class="HOEnZb"><div class="h5"> -- James Hunt ____________________________________ <a href="http://upstart.ubuntu.com/cookbook" target="_blank">http://upstart.ubuntu.com/cookbook</a> <a href="http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf" target="_blank">http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf</a> </div></div></blockquote></div> </div>