netblue30 / firejail

Linux namespaces and seccomp-bpf sandbox
https://firejail.wordpress.com
GNU General Public License v2.0
5.79k stars 567 forks source link

support for Kerberos/GSSAPI (e.g. browser SPNEGO) #5492

Open loveshack opened 1 year ago

loveshack commented 1 year ago

This enables Kerberos authentication, e.g. SPNEGO in browsers. It will presumably also work for other things with Kerberos/GSSAPI authN like ssh (which I can't easily test currently). Most probably won't need /etc/gss, though. The KCM socket location might be configured differently from the default below with sssd-kcm.

I've tested some combinations of packaged Firefox and Brave using FILE: and KCM credential caches, under packaged Firejail v0.9.70 in Debian and RHEL 8. KEYRING doesn't work, but isn't advised anyhow as it's not namespaced.

# gssapi (with FILE: or KCM: ccache, but not KEYRING:):
whitelist /etc/krb5*
# FILE:
whitelist /tmp/krb5cc_*
# KCM:
whitelist /var/run/.heim_org.h5l.kcm-socket
# Debian
whitelist /etc/ssl
# Fedora
whitelist /etc/pki
# (Not needed for the Kerberos mechanism)
whitelist /etc/gss
# end gssapi
Thulium-Drake commented 1 year ago

I had to it slightly differently on my Debian system (I also had to configure SSSD to use KCM as Debian by default does KEYRING), but I ran into klist: Included profile directory could not be read while initializing krb5 errors

Adding the line below fixed that:

whitelist /var/lib/sss/pubconf/krb5.include.d/
loveshack commented 1 year ago

I had to it slightly differently on my Debian system (I also had to configure SSSD to use KCM as Debian by default does KEYRING),

It's FILE: for me when krb5-user creates krb5.conf on Debian 11, but no matter.

but I ran into klist: Included profile directory could not be read while initializing krb5 errors

Adding the line below fixed that:

whitelist /var/lib/sss/pubconf/krb5.include.d/

Ah, thanks. I just have pam_krb5, and that doesn't exist.

ghost commented 1 year ago

This is not working for me at least. DO you have a full example? Where are you dropping the overrides? Debian based distribution.

ghost commented 1 year ago

KEYRING: is actually needed by the way. I don't know in which cases FILE or KCM would ever be a good idea or even found in real-world deployments.

(I am aware of https://docs.pagure.org/sssd.sssd/design_pages/kcm.html and I still think the benefits of KCM are debatable in practice)

Thulium-Drake commented 1 year ago

I use KCM becuase of one reason mostly, it's the default config in RHEL8+ and it works better in a namespaced environment (podman etc.).

What I did on my machine:

Valid starting Expires Service principal 2023-06-01 16:42:43 2023-06-02 16:19:32 krbtgt/EXAMPLE.NET@EXAMPLE.NET renew until 2023-06-08 16:42:43


- Configure a profile for Firefox

name firefox

Allow access to sockets for Keepass browser integration

noblacklist ${RUNUSER}/app mkdir ${RUNUSER}/app/org.keepassxc.KeePassXC whitelist ${RUNUSER}/app/org.keepassxc.KeePassXC

Allow Kerberos ticket access for SSO

whitelist /var/lib/sss/pubconf/krb5.include.d/ noblacklist /run/.heim_org.h5l.kcm-socket whitelist /run/.heim_org.h5l.kcm-socket

include /home/me/firejails/filesystems.inc # Some basic blacklists for my private data, see below include /etc/firejail/firefox.profile


- Optional extra profile for filesystems I want to protect/allow

noblacklist ${HOME}/.pulse whitelist ${HOME}/.pulse

blacklist /data blacklist /mnt

ghost commented 1 year ago

@Thulium-Drake How are you managing the profile? ex. what is the preferred destination for local mods. I have been partial to using /etc/firejail/*.local but the way overrides work don't seem well documented. For example using whitelist directives seems to break the parent profile for me.

I'm not keen on using KCM as a rule of thumb only because of the implications of having a file on disk. This introduces other security risks, since the KEYRING subsystem is very easy to control as it is accessible only via keyctl (system calls). With the current climate of Spectre-type issues and the attack surface of drive firmware (ex. SSDs), plus the entire IO layer of the kernel, once the credentials/token hit the disk they become easier to target. Of course KEYRING is not free of issues (any kernel exploit would yield access) but it does limit things to a single point of failure, which in this case, is a good thing.

I nonetheless configured a test system for KCM while I figure out how to adjust seccomp in the profile to be able to do keyctl calls. Testing on Ubuntu "jammy".

glitsj16 commented 1 year ago

@vogelfreiheit

How are you managing the profile? ex. what is the preferred destination for local mods. I have been partial to using /etc/firejail/*.local but the way overrides work don't seem well documented. For example using whitelist directives seems to break the parent profile for me.

You can find detailed info on our wiki pages: Creating overrides. The include logic can become somewhat complex and extra attention should be payed as to which local override is suited for overriding any of the included .inc files. I don't want to hijack your exchange with @Thulium-Drake but it would help if you could provide an example of your experienced breakage. Just my 2 cents :)

ghost commented 1 year ago

@glitsj16 Absolutely no hijacking taken, feel free to contribute. I just read the whitelist nuances, thanks. That makes sense now.

This is what I am testing in a VM in a client-IPA server configuration:

ignore private-dev

noblacklist /etc/krb5.conf.d
noblacklist /var/lib/sss/pubconf/krb5.include.d/
noblacklist /proc/keys
noblacklist /etc/krb5.conf
noblacklist /etc/krb5.conf.d/

# Allow access to sockets for Keepass browser integration
noblacklist ${RUNUSER}/app
mkdir ${RUNUSER}/app/org.keepassxc.KeePassXC
whitelist ${RUNUSER}/app/org.keepassxc.KeePassXC

# Allow Kerberos ticket access for SSO
whitelist /var/lib/sss/pubconf/krb5.include.d/
noblacklist /run/.heim_org.h5l.kcm-socket
whitelist /run/.heim_org.h5l.kcm-socket

seccomp !keyctl

(for firefox.local in /etc/firejail)

No dice.

ghost commented 1 year ago

@glitsj16 Absolutely no hijacking taken, feel free to contribute. I just read the whitelist nuances, thanks. That makes sense now.

This is what I am testing in a VM in a client-IPA server configuration:

ignore private-dev

noblacklist /etc/krb5.conf.d
noblacklist /var/lib/sss/pubconf/krb5.include.d/
noblacklist /proc/keys
noblacklist /etc/krb5.conf
noblacklist /etc/krb5.conf.d/

# Allow access to sockets for Keepass browser integration
noblacklist ${RUNUSER}/app
mkdir ${RUNUSER}/app/org.keepassxc.KeePassXC
whitelist ${RUNUSER}/app/org.keepassxc.KeePassXC

# Allow Kerberos ticket access for SSO
whitelist /var/lib/sss/pubconf/krb5.include.d/
noblacklist /run/.heim_org.h5l.kcm-socket
whitelist /run/.heim_org.h5l.kcm-socket

seccomp !keyctl

(for firefox.local in /etc/firejail)

No dice.

ghost commented 1 year ago

Also: KCM will break NFS it seems.

Thulium-Drake commented 1 year ago

I have a git repo in my homedir which houses all my profiles. I wrote the following script, which will check if I have a custom profile for a specific app, if not, it 'just' starts with the default profile from /etc/firejail

#!/bin/bash
# Check if we have a profile for the started application, then run it

CMD=$1
shift
CMD_ARGS=$@
CMD_BIN=$(which $CMD)
FJ_BIN=$(which firejail)

CUSTOM_FIREJAILS=$HOME/firejails
DEFAULT_FIREJAILS=/etc/firejail
PROFILE=false
DEFAULT_PROFILE=false

if [[ -f $CUSTOM_FIREJAILS/${CMD}.profile ]]
then
  PROFILE=true
elif [[ -f $DEFAULT_FIREJAILS/${CMD}.profile ]]
then
  DEFAULT_PROFILE=true
fi

if $PROFILE
then
  $FJ_BIN --profile=$CUSTOM_FIREJAILS/$CMD.profile $CMD_BIN $CMD_ARGS
elif $DEFAULT_PROFILE
then
  zenity --warning --text 'No firejail custom profile detected, using default' --width=300 --timeout=5 &
  $FJ_BIN --profile=$DEFAULT_FIREJAILS/$CMD.profile $CMD_BIN $CMD_ARGS
fi

With this in place, i run /home/me/firejails/fjwrapper firefox to start Firefox

It may be a bit rought around the edges, but it works pretty well :-)

loveshack commented 1 year ago

This clearly isn't the place for argument and support of Kerberos applications generally.

If you really need this as an include fragment, with a suggestion for debugging, see https://fx.srht.site/posts/2022-05-13-spnego.html#sandboxes-like-firejail I don't know if the Kerberos trace will help if you want to add KEYRING support, but I guess other applications with profiles use the Linux keyring. Obviously do follow up with any success at that.

glitsj16 commented 1 year ago

I'm not familiar with Kerberos/GSSAPI but I wanted to make some general comments on some of the profile options mentioned in this thread.

Using noblacklist foo only makes sense for items that have blacklist foo in other relevant profile files. This probably sounds pedantic, but it can really help keeping things less convulated/overly-complex. For example, these items are not blacklisted anywhere AFAICT and their noblacklist lines can be dropped:

/etc/krb5.conf
/etc/krb5.conf.d
/etc/krb5.conf.d/
/var/lib/sss/pubconf/krb5.include.d/

About whitelisting /etc/foo. For Firefox we enable private-etc in firefox-common.inc. IMO any additional items needed from /etc for this Kerberos/GSSAPI issue should be added to private-etc (instead of needing to be whitelisted).

Another remark relates to how support for KeePassXC is enabled here.

# Allow access to sockets for Keepass browser integration noblacklist ${RUNUSER}/app mkdir ${RUNUSER}/app/org.keepassxc.KeePassXC whitelist ${RUNUSER}/app/org.keepassxc.KeePassXC

Compare this with https://github.com/netblue30/firejail/blob/30ff544b8fc4362d51d10d28d633600d5e714ae4/etc/profile-a-l/firefox.profile?#L32-L35

rusty-snake commented 1 year ago

@glitsj16 https://github.com/netblue30/firejail/discussions/5444#discussioncomment-4039950

ghost commented 1 year ago

This clearly isn't the place for argument and support of Kerberos applications generally. If you really need this as an include fragment, with a suggestion for debugging, see https://fx.srht.site/posts/2022-05-13-spnego.html#sandboxes-like-firejail I don't know if the Kerberos trace will help if you want to add KEYRING support, but I guess other applications with profiles use the Linux keyring. Obviously do follow up with any success at that.

This is not a discussion about "Kerberos applications generally", this is a discussion of firejail breaking SPNEGO/Kerberos and KEYRING access, which are ubiquitous in many environments. Perhaps not the home Linux or hobbyist user, but everywhere else including education and enterprise they most definitely are.

There is a very valid argument to be made about including a boolean or similar option to explicitly support auth negotiation in all profiles.