[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-security-discuss
Subject:    Re: System D-Bus in TX environment
From:       Christoph Schuba <Christoph.Schuba () sun ! com>
Date:       2008-09-17 15:12:28
Message-ID: 48D11E5C.5080409 () Sun ! COM
[Download RAW message or body]

Darren,

one more use case for DBUS in a TX environment:

Glenn, Gary, and I discussed the other day how the audio device
allocation could behave if you have say multiple potential audio
consumers in different labeled zones.

Imagine two VBox-based OSes in different zones. Both have a virtual
audio device that VBox provides, however, at most one VBox has access
to the real device at any given time, based on how the device is
allocated via the device allocator. At VBox startup time, VBox sees
what's underneath it (or what isn't) correctly, however, if the real
device underneath is taken away from one VBox (say V1) and given to
another (say V2), the following happens. V1's audio stops working, as
expected, however, V2's audio does not start working, because V2 does
not rescan/get notified of the change in devices underneath it.
A per zone D-Bus access could be the answer here. The global zone
(on behalf of the device allocator) would put the appropriate
"new audio device" or "audio device disappeared: message
on the D-Bus in the associated labaled zone, and VBox would get
the notification by reading those messages.

-Christoph


Brian Cameron wrote:
> Darren:
> 
>> I'd like to have some discussion of the System D-Bus in a TX environment 
>> - sorry for the long To: list but I'm not sure all the people with D-Bus 
>> and TX experience are necessarily on security-discuss.
>>
>> Currently zones that represent TX labels have a session D-Bus but no 
>> access to the system D-Bus.
>>
>> * What could we gain by providing access to the system D-Bus in a 
>> labeled zone ?
>>    What would work that is useful that doesn't now ?
>>    What new things could we do using D-Bus that would benefit labeled
>>    zones ?
>>    Are there existing things we could solve easier ?
> 
> Artem should confirm since he knows better than I, but I think the only
> thing that uses the system bus on Solaris is HAL.  So, I suspect that
> removable media support in zones may not work in a reasonable way.
> But it's perhaps also unclear how removable media should be mounted
> in a multi-zone environment.
> 
> There are some other projects in Linux that use the system service.
> I believe that there is a Linux package installation system built
> around the D-Bus system service.  However, there are obviously no
> plans to integrate that into Solaris.  I believe PolicyKit may also
> use the system bus, but it is another program we are unlikely to
> integrate anytime soon, if at all.
> 
>> * What type of information is on the system D-Bus ?
>>    How sensitive is that likely to be ?
>>    Remember that we must be very careful about opening up
>>    channels that could be used to communicate between labeled zones.
> 
> I'd think mostly just information about removable media events, and
> access to the removable media.  In terms of security, you probably
> want to make sure that things get mounted to the intended zone.
> Not sure how you would know.
> 
> I'm guessing most Trusted users probably don't use TJDS to rip CD's
> to their external hard drive.
> 
>> * Is access always read/write or would read only access be useful / 
>> available ?
> 
> I'd think people would want to read and write to their removable media,
> but reading-only is probably better than nothing.
> 
>> * Would a trusted proxy be needed to filter what information can be 
>> seen? [ I and Stephen both suspect so but lets not assume that is the 
>> only solution ].
> 
> I'd think some mechanism to make sure that when media is mounted, it
> gets mounted to the right zone(s).  Perhaps this could be pre-configured
> in some way.  You probably don't want to ping users in all running zones
> with a dialog asking them "Who owns the drive you just plugged in?
> First response wins"
> 
> Brian
> _______________________________________________
> security-discuss mailing list
> security-discuss@opensolaris.org
> 
_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]