From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] kdialog and Chromium
Date: Tue, 31 Jul 2012 14:32:39 -0400 [thread overview]
Message-ID: <501824C7.6020505@tresys.com> (raw)
In-Reply-To: <20120727091218.GB13778@siphos.be>
On 07/27/12 05:12, Sven Vermeulen wrote:
> On Fri, Jul 27, 2012 at 04:14:43PM +1000, Russell Coker wrote:
>> Currently on Debian/Wheezy it's impossible to download files in Chromium when
>> you are running a KDE session.
>>
>> Chromium launches kdialog to display the dialog box to ask where the file
>> should be saves. kdialog wants to write to files such as
>> ~/.kde/share/config/kdebugrc.lock which isn't permitted for mozilla_t.
>>
>> One possibility that occurs to me is to have kdialog transition to user_t.
>> Transitioning from mozilla_t isn't generally a good thing, and breaks the case
>> of running mozilla_t from multiple user domains (multiple user domains is
>> essentially a broken feature of the policy anyway).
>>
>> Apart from modifying kdialog to not depend on the ability to write to
>> kdebugrc.lock what can I do to solve this?
>
> Russel, sorry for sending you previous mails privately, wasn't my intention.
>
> As I said, I'm working on a (separate[1]) domain for chromium and hit similar
> issues too (for instance when accessing ~/.pki) since I am trying to get the
> browsers running without requiring access to user_home_t stuff.
>
> Perhaps we can allow for a sharable lock file type (kde_lock_t) and allow
> the domain search rights in the kde_home_t stuff (I'm assuming these are the
> domains, I don't have any kde_* stuff here) and an automated file transition
> when a file with the name "kdebugrc.lock" is written in kde_home_t to
> kde_lock_t ?
At the moment, I don't have any suggestions beyond something like this. Not unless you want a conditional for writing out files to the home dir.
> [1] Chromium itself can be built with SELinux-enabled, but then requires
> that the policy supports a domain called chromium_renderer_t (which it
> dynamically transitions to). It doesn't make sense to include this in the
> mozilla_t domain.
Is chromium_renderer_t hard coded into Chromium or does it sanely expect an appconfig file (like initrc_context or userhelper_context)?
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
next prev parent reply other threads:[~2012-07-31 18:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-27 6:14 [refpolicy] kdialog and Chromium Russell Coker
2012-07-27 9:12 ` Sven Vermeulen
2012-07-31 18:32 ` Christopher J. PeBenito [this message]
2012-07-31 19:13 ` Sven Vermeulen
2012-07-31 19:22 ` Christopher J. PeBenito
2012-07-31 19:28 ` Sven Vermeulen
2012-07-31 22:59 ` Dominick Grift
2012-07-31 23:20 ` Dominick Grift
[not found] ` <CAPzO=NwtZ3C1+t5L-byURbdxyXuq6Pb3-4EZWw6eVArkCe8qhw@mail.gmail.com>
2012-08-01 6:47 ` Sven Vermeulen
2012-08-01 14:41 ` Dominick Grift
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501824C7.6020505@tresys.com \
--to=cpebenito@tresys.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.