On Tue, Nov 20, 2012 at 10:53 AM, James Hunt <[email protected]> wrote:
> Hi Evan, > > 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 > > 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. > 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. 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? > 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). > 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'. > 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? > > > Thoughts? > > > > Cheers, > > Evan > > > > > > On Tue, Nov 20, 2012 at 5:09 AM, James Hunt <[email protected] > > <mailto:[email protected]>> wrote: > > > > Here is the draft plan for 'Enhanced Upstart User Sessions' ([1]), > which will be > > used to supervise desktop sessions in Ubuntu: > > > > > https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions > > > > = 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] - > > > https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upstart-user-session-enhancements > > -- > > James Hunt > > ____________________________________ > > http://upstart.ubuntu.com/cookbook > > http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf > > > > -- > > upstart-devel mailing list > > [email protected] <mailto: > [email protected]> > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/upstart-devel > > > > > > 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. > 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. > [2] - Since I don't think user jobs are widely used, and are in fact > currently > disabled in Ubuntu. > I certainly have never bothered to set them up. On Tue, Nov 20, 2012 at 10:53 AM, James Hunt <[email protected]> wrote: > Hi Evan, > > 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 > > 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'. > > > > > Thoughts? > > > > Cheers, > > Evan > > > > > > On Tue, Nov 20, 2012 at 5:09 AM, James Hunt <[email protected] > > <mailto:[email protected]>> wrote: > > > > Here is the draft plan for 'Enhanced Upstart User Sessions' ([1]), > which will be > > used to supervise desktop sessions in Ubuntu: > > > > > https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions > > > > = 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] - > > > https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upstart-user-session-enhancements > > -- > > James Hunt > > ____________________________________ > > http://upstart.ubuntu.com/cookbook > > http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf > > > > -- > > upstart-devel mailing list > > [email protected] <mailto: > [email protected]> > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/upstart-devel > > > > > > 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. > > -- > James Hunt > ____________________________________ > http://upstart.ubuntu.com/cookbook > http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf >
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
