Enhanced Upstart User Sessions for the Raring desktop

Tue Nov 20 17:24:03 UTC 2012

On Tue, Nov 20, 2012 at 10:53 AM, James Hunt <james.hunt at ubuntu.com> 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 <james.hunt at ubuntu.com
> > <mailto:james.hunt at ubuntu.com>> 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
> >     upstart-devel at lists.ubuntu.com <mailto:
> upstart-devel at lists.ubuntu.com>
> >     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 <james.hunt at ubuntu.com> 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 <james.hunt at ubuntu.com
> > <mailto:james.hunt at ubuntu.com>> 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
> >     upstart-devel at lists.ubuntu.com <mailto:
> upstart-devel at lists.ubuntu.com>
> >     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20121120/55ffcc21/attachment-0001.html>