Enhanced Upstart User Sessions for the Raring desktop

Tue Nov 20 15:54:57 UTC 2012

-------- Original Message --------
Subject: Re: Enhanced Upstart User Sessions for the Raring desktop
Date: Tue, 20 Nov 2012 15:53:40 +0000
From: James Hunt <james.hunt at ubuntu.com>
Reply-To: james.hunt at ubuntu.com
To: Evan Huus <eapache at gmail.com>
CC: Upstart Devel List <upstart-devel at lists.ubuntu.com>, jamie at ubuntu.com,
  Kees Cook <keescook at google.com>

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

-- 
upstart-devel mailing list
upstart-devel at lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/upstart-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20121120/11a60e9b/attachment.pgp>