Enhanced Upstart User Sessions for the Raring desktop
Kees Cook
keescook at chromium.org
Tue Nov 20 18:18:50 UTC 2012
On Tue, Nov 20, 2012 at 9:24 AM, Evan Huus <eapache at gmail.com> wrote:
> On Tue, Nov 20, 2012 at 10:53 AM, James Hunt <james.hunt at ubuntu.com> wrote:
>> On 20/11/12 13:58, Evan Huus wrote:
>> > 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.
I like the idea of it needing to explicitly send such events. The
down-side is that perhaps that means suddenly all events will just be
written by their authors to explicitly use ":all:", and then this
design choice wasn't useful. That said, it seems like making user
session "omniscient" is asking for trouble.
>> 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).
Or maybe malware could use events to improve timing attacks against
system services ("oh, it's starting, move those files around to
confuse it!").
User sessions should not see each other's events, so I wouldn't think
system should either by default.
>> 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?
This is interesting, but seems like a lot of effort with the chance to
go wrong when explicitly configurations would be better. Default to
tighter security, and open it up as needed.
And, of course, document this well so people don't get surprised if
something goes weird. :)
-Kees
>
>> >
>> > 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
>
>
--
Kees Cook
Chrome OS Security
More information about the upstart-devel
mailing list