reasoning of disabling SELinux in Qubes default template

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

I'm wondering why SELinux is disabled by default in Qubes' default
Fedora template. Searching the mailing list archive lets me guess that
SELinux was still enabled on the F18 template?

Is it a major headache to maintain a SELinux enabled template or has
it simply been disabled because users can use the isolation provided
by Xen / separate AppVMs anyway?


Background

While I can't afford a new disposableVM for every URL I click (in an
emailVM or rssVM), I'd still like to have the same separation level
that I have on a non-Qubes system where SELinux sandboxes are used to
have at least some separation between browser instances.

Would you consider enabling SELinux in the default template again?

thanks,
Joonas
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTnAQkAAoJEG58zmw5nc+v2b4P/RqidEordVPm11nJlYKCXHsK
8/pYkFQXbGVXmfxxd3EHCzZQ7kTO/hSmJqUHQuSzNbEK9GfiyeEufVxiHAq6U2rV
X8ktiPt/eFznqQQMSZjZ7HUJJUrqsGgF5iY2K4nE40eZiC1ce1A0TLXovAQ0KznG
B2xjvvx373cim0oq+XjqfMaGjrKVkHfVzEbiXTcbh7nkaDuczciqWlmZa1erm3KE
jDPOTmt5iB2BH0wAqEorVXfzLFbKtXVoiUNWZYKtgM/SjACBomYTa3Do1oI679CL
JPyssLzXLDs2YWTJB9o5ifWKMYraLMXp+6OldBwQoSE0BadtsYA13RIRGPOiuVrA
193J5tKTqKyPlk+HnlCI2VV5ynNmgMatFAoKijJiMERlku3BcwLLsdQJYMNgZqYk
tvxzpH3+AOg+4kmCMhzHvZ5YnBH885z30p1EOrXwEO1lxRBD1LWqTcVVFPZbsN5I
P+cpAsbz7Pm4rEBUMrzPd7nj6H5mmikpcTH5Vtw5oZJnUhLVtX1dtAJK501ikV9q
EVaXapOMRBOIrTH5ZYOMWVcGWMMKFxykl8m9w1cGQSnBDgsMd7Ofrr+LEa1a3H/v
Fq2qTnbm4e5L1VWdX6P7qP/fDV88md1gUuoyRsjQutzlw360PynLuFba7rh5z7OG
ziyUYdXz6qLOSdU/gtI+
=+mDi
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

On 06/14/14 10:13, Joonas Lehtonen wrote:
> Hi,
>
> I'm wondering why SELinux is disabled by default in Qubes' default
> Fedora template. Searching the mailing list archive lets me guess that
> SELinux was still enabled on the F18 template?
>
> Is it a major headache to maintain a SELinux enabled template or has
> it simply been disabled because users can use the isolation provided
> by Xen / separate AppVMs anyway?
>
>
> Background
>
> While I can't afford a new disposableVM for every URL I click (in an
> emailVM or rssVM), I'd still like to have the same separation level
> that I have on a non-Qubes system where SELinux sandboxes are used to
> have at least some separation between browser instances.
>
> Would you consider enabling SELinux in the default template again?
>

AFAIU SELinux still provides no GUI-level isolation (X-level isolation
if you wish), so for this to make any sense within one AppVM you would
need to also make sure to run each of your browsers with a different
Xorg instance (in this same AppVM), each (X server) running as non-root
and a different user.

Plus it would make no sense with the Qubes default suborders file, but I
just saw in the other thread you (and others) have some solutions to
this (qubes.VMAuth/VMSudo), but I don't think we would like to merge
such things at this stage for R2.

joanna.

[Marek Marczykowski-Górecki]

On 14.06.2014 10:13, Joonas Lehtonen wrote:
> Hi,
>
> I'm wondering why SELinux is disabled by default in Qubes' default
> Fedora template. Searching the mailing list archive lets me guess that
> SELinux was still enabled on the F18 template?

No, it wasn't.

> Is it a major headache to maintain a SELinux enabled template or has
> it simply been disabled because users can use the isolation provided
> by Xen / separate AppVMs anyway?

Both. But enabling SELinux in template would make some sense - not very big
(see Joanna's post), but still some another layer of protection.

> Background
>
> While I can't afford a new disposableVM for every URL I click (in an
> emailVM or rssVM), I'd still like to have the same separation level
> that I have on a non-Qubes system where SELinux sandboxes are used to
> have at least some separation between browser instances.
>
> Would you consider enabling SELinux in the default template again?

If anyone want to implement this properly (not breaking qrexec etc), I'll
accept the patches (but probably not before final R2 anyway).

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> AFAIU SELinux still provides no GUI-level isolation (X-level
> isolation if you wish), so for this to make any sense within one
> AppVM you would need to also make sure to run each of your browsers
> with a different Xorg instance (in this same AppVM), each (X
> server) running as non-root and a different user.

there seems to be at least some difference to default X without Xephyr
as one mentioned on your blog a while ago [1]


but it is not all black and white. I would be already be happy if the
cookie in sandbox 1 doesn't get propagated to a website visited in
sandbox 2 and everything gets deleted on window closure.

After all I understand that in-AppVM-stuff is not really in scope of
the Qubes OS project - I was just wondering if SELinux would be
possible without much hassle, but now I know.

Thanks for your answers.

> Plus it would make no sense with the Qubes default suborders file

Has sudo any impact on a default sandbox_web_t domain?


[1]
http://theinvisiblethings.blogspot.fr/2011/04/linux-security-circus-on-gui-isolation.html?showComment=1303574236988#c7925540745482403781
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTscfuAAoJEG58zmw5nc+v7JsQALLAJ4kP0vNpy8L+Gd6YIFfH
nee6NwWXKX8+BzAhGFCoCCM2XImnhcTTjZOrJmqIsFQ2/yIV1jF/LeNhn/QptwXB
OCd2t4izdnJA/X8QYV7+Hd/kC31ERsHk0oBNt2lfidQ3Gs4X2qteNg2TyCP+/SMJ
CRWx1E2eyJzFYpoJsxRlKlR6mLEPPCVmpUgCVj6e4JNclWguhqUqzPQQHLBZsMMB
lNNX4T4fDs152/6VsZpZqa8ujSRXlkhz7HkmDVvrDmKqkHh6X+xLgac2BzcoVVZL
JDsj/UcnPWthoHGyfhTXOYMuqlWTRK1irN/LJhlhVmr8CVFYdGw6vo8ydkptYXvB
SLnHeVVIXZ8y8yBljx554a3dDaeZ0J+4GhA4jG5g1fRhdtGkfxLsKim3SSn9YJyr
9jH7Tai+Xux4SW/5kVaOhV5+yexYdBrShwp1meTgWaaKUrc7oanWjqd2ozJE0ObG
8ATTU9+OyAonSpKAiZdfdl8hUmXYZjHFQxDf0K69KNQoS//mBqfmx9JYzPHcvMfD
OrHuZ38rlY0bLcJqkOj5wNLh/1jLwI0qzuhds2MkRSo0WX1xMwD99utEfZEEZvoU
HYk/Ct3nEdWYXPqAFGIyZGuf+DakrZpJYyDDbEFge5PEs4OhRrWbUyouyTOUNO7n
SY4J3s256SEEJzJvbtoH
=XL7f
-----END PGP SIGNATURE-----