I switched to Fedora a few months ago, after using other distros for a long time. The reason I switched to Fedora is because SELinux is great a isolating applications, and I do want to feel comfortable knowing that the applications I use are confined.
Considering more security means less comfort, I totally understand why SELinux policies are not enabled by default after a default install. I did some research on the matter and I decided to write the following repo: G / selinux_browser_module ¡ GitLab
This gives me the comfort I need, by isolating the chromium and the firefox browsers. If you guys like the idea, and think some improvements could be done to it, please let me know. Also please shout out if you think stuff like this should come by default with Fedora (maybe within a hardened version, since the main focus of Fedora Workstation is to provide great user experience using Gnome).
Very nice, I think more desktop software should be confined, even if most are not security sensitive.
But what make it hard is not that more security make less comfort, it is that we do not have a good UX for that and too much can be done by a browser to be limited without falling in the Windows vista style popup, where people will just hit âyesâ.
For example, firefox need to read any file of the user, in case the user need to send one by mail. So there isnât much to be limited here by default. And the the browser should also be able to write anywhere, cause I may want to download things in some directory. So again, not much to do here on SELinux.
Not to mention that for most people, the type of attack done on a browser are in the browser, like stealing firefox credentials (not much SELinux can do), injecting js to do crypto mining (not much that can be done either).
At best, SELinux can prevent a exploited firefox from running more bad code (or become root and change DNS), but it can be worked around with dropping a extension that do serve as a botnet in the browser (so running in firefox, when firefox start, and thatâs authorized because extensions are installed from within the browser, so again, not much SELinux can do). Chromium already have a sandbox to prevent that kinda of stuff, which is great but unfortunate given the recent push from Google to be more privacy intrusive (see youtube, recent chrome discussion, etc). People told me that their new CFO is pushing for more money to be mde, hence these moves (and others internal ones).
So, rather than using SELinux, I think that using flatpak for that is better, because flatpak do have a UX to not let firefox open every file, but thatâs just covering some of the risks. Doing more would requires change to firefox, some where are under the way. And IIRC, SELinux was used to confine java/flash in the past, which were also the biggest security problem.
Have you looked at the SELinux sandbox project too, and the Qubes linux distribution ? Maybe some of the idea of QUbes could be reused for that, such as having a throw away empty profile for firefox in a wa that do not involve meddling with CLI.
For example, firefox need to read any file of the user, in case the user need to send one by mail. So there isnât much to be limited here by default. And the the browser should also be able to write anywhere, cause I may want to download things in some directory. So again, not much to do here on SELinux.
No, we must be sure that firefox can not access any file of the user, because that means that firefox can also access ssh and pgp keys⌠and that it can also access a lot of file that have nothing to do with browsers. And again, it should NOT be able to write anywhere, it should be able to write ONLY to the downloads folder. This is already configured within the selinux browser module I did, so that firefox canât read&write in random locations.
I thought about flatpak and I saw a lot of people use docker for confining desktop applications. The problem with flatpak is that nobody created a proper flatpak for browsers yet, so somebody needs to pick that up ⌠and regarding Docker, Chromium will not run unless you change a parameter in the kernel, which is too invasive.
But a user might want to send them by a webmail or upload them. And for ssh keys and pgp keys, I think SELinux is the wrong answer, cause ideally, this shouldnât even be stored on disk but stored on something more secure, like a smartcard. For 50 US$, one can get a Yubikey nano. Or get a usb reader + a 22⏠smartcard. Or just use the TPM on recent laptop with GitHub - ThomasHabets/simple-tpm-pk11: Simple PKCS11 provider for TPM chips . Then a compromised browser canât steal the key.
There is also the case of certificate authentication, so the browser would need to access some of the data labelled as sensible. Granted, this is kinda obscure, but so would GPG for most users.
I am also kinda unsure of how SELinux interact with D-Bus, since the policy you linked let firefox talk to unconfined_t over DB-us, which likely allow lots of access. For example, on my system, someone able to use D-Bus can read and write gnome configuration, and I would be very surprised this cannot be used to change some path to run something at start somehow. Then a attacker can download something on disk in ~/Downloads, set +x, then do the config change and wait. Or just drop the file and ask to gnome-shell to load it as a extension by D-Bus (that seems to be something that can be done from a quick reading of the interface with d-feet). Maybe I am wrong on what can be done, and I know that we can apply SELinux policy on D-Bus but I do not know how thatâs done in practice.
So there is a flatpak for firefox nightly, not sure how correct it is.
But ultimately, neither SELinux nor flatpak sandbox would prevent much on the interesting attacks.
For example, they wouldnât be able to block much on the network side, cause a browser can use webrtc to open any port and thatâs used for video conference which is a rather popular use of a browser these days. The same goes for webcam/micro (video conf), or raw usb access for U2F (which then open to weird attack vectors). Or again, files. Of course, one could block, but that would be inconvenient and result into people not using flatpak nor SELinux.
Yea, the status is not that good. However I would not eliminate this isolation layer. Even if itâs not perfect protection, itâs some protection, so I would stick to jessfrazz containers, or flatpaks (as soon as some decent ones are out), or SELinux. If you run containers on Fedora, you also benefit from containers being protected from each other with SELinux MCS.
Yea, there also is a policy for Firefox. I am actually extending those policies with my own module. Building something from scratch is hard and you want to use as much of the existing policies within Fedora. There is an insane amount of interactions between different stuff on the system, and understanding all of it takes years of experience with SELinux.
GL&HF. I switched to i3wm some months ago, after building up my courage for the last year. Not going back ever. Once you go i3wm, you never go back.
I donât need that. However, I am using Evolution for mails so I am kind of scared of the idea of a security issue there, since it uses my private key for decrypting and signing mails.
I never used TPM. Thank you for pointing that out. I will do my homework and see what comes out of this. However the problem here is that at least for mail I would have to carry my laptop all over the place, so that I can also read my mail from home.
Regarding YubiKey / Smartcard, I never owned one. That is something I want to try out, so that I also understand the vulnerabilities and the limitations. If you have experience in this area, please share.
So for a while, I did use simple-tpm-pkcs11 for my work ssh key, and it was working well (back in 2014/2015). Someone would need to have access to both the unlocked disk (there is a encrypted blob there) and the motherboard for getting any access. The problem appeared in 2017 while I was traveling around Europe, when the frame of my laptop screen began to crack, and that I had to potentially send it to repair. Suddenly, I realized that I wasnât sure to get back the same motherboard if it got fried, and even if I did waited for new laptop, that I would have issue when switching.
So I switched to using a smartcard in summer 2017, with a spare yubikey I had. It took me a while to just change my ssh keys everywhere (I listed around 30 to 40 systems). I already used yubikey for the 2FA auth at work, so this was quite easy to just also use my key for testing. I decided to generate my ssh key directly on the hardware to prevent possible leaks, but this turned out to be also a bad idea. Yubikey did receive lots of criticism for switching from free software code that could be uploaded to code that was burned in the silicon in the microcontroller back in 2016 (Yubico: Secure hardware vs. open source [LWN.net]). While I do care about free software, this was a tradeoff I was willing to make for the form factor, and my understanding is that they didnât really had much choice anyway given the current industry (with NDA all over the place, etc).
So I switched again ssh keys (the process this time was much faster, since I did had my list from summer), and now, my current setup is to have 2 yubikey nano, 1 holding 1 ssh key, the other one holding 2 keys ( same key as first + a backup key in case the first has a issue). The first yubikey is on my laptop, the 2nd is a backup in case I lose the first. I upload the 2 keys everywhere, so if I lose the first, I can still connect, and I can remove the lost key without losing access. And I do have a clear text version of the 2 ssh keys on a encrypted usb stick safely stored in case I need to replicate one. And 1 spare key to replace the one that would be lost.
My biggest issue in the past was that the ssh-agent of seahorse didnât support adding pkcs11 smartcard, and I wasnât even sure where to start to add that, as I lost myself in the several layer of crypto stack (for people who never seen the diagram: https://assets.flameeyes.eu/2011/04/nss-pkcs11 ). Now, this is solved on recent GNOME so I can just do:
ssh-add -s /usr/lib64/opensc-pkcs11.so
Then it ask for the PIN and I can use it in my agent.
On my Silverblue laptop , I need to layer opensc and that work. As for the initial setup, my first script:
#!/bin/bash
PUBLIC=$(mktemp --suffix=.pem)
CERT=$(mktemp --suffix=.pem)
SLOT=${SLOT:-9a}
ALGO=${ALGO:-RSA2048}
yubico-piv-tool -s $SLOT -a generate -A $ALGO -o $PUBLIC
yubico-piv-tool -s $SLOT -a verify-pin -P 123456 -a selfsign-certificate \
-S "/CN=SSH key of $USER, slot $SLOT/" -i $PUBLIC -o $CERT
yubico-piv-tool -s $SLOT -a import-certificate -i $CERT
echo "the current key is:"
ssh-keygen -D /usr/lib64/opensc-pkcs11.so
This do generate the certificate on the key itself.
My production script still has a reminder to not use that due to ROCA. Depending on the version of the key you have, you might go for more than RSA 2048, but I think openssh do not support ECDSA keys on pkcs11, despites patch floating. Openssh in Fedora is patched for that: Fedora 28: Better smart card support in OpenSSH - Fedora Magazine, but thatâs not a risk I am willing to try in case I need to use the key on another laptop (something I consider more likely than a crypto breaktrough regarding RSA factoring). Not to mention there is still old stuff around that do not support ECDSA, as one of my coworker did painfully found out (and letâs not throw quantum crypto out there, as I kinda think people panic for nothing at the moment: encryption - Why is ECC more vulnerable than RSA in a post-quantum world? - Information Security Stack Exchange ).
My current script is generating offline so I can keep a backup copy:
#!/bin/bash
set -e
if [ $# == 1 ]; then
DIR=$1
else
DIR=$(mktemp --directory ${XDG_RUNTIME_DIR}/ssh_yubi_XXXXXXXXXX)
fi
# hardcoded, since that's the max we can store on a smartcard for now
SIZE=2048
PREFIX=${PREFIX:-SSH}
echo "Working in $DIR"
SLOT=${SLOT:-9a}
KEY_PREFIX=newkey
NEW_KEYFILE=$DIR/$KEY_PREFIX
cd $DIR
if [ ! -f "$DIR/$KEY_PREFIX" ]; then
ssh-keygen -N "" -b $SIZE -q -f $DIR/$KEY_PREFIX
fi
openssl rsa -in $DIR/$KEY_PREFIX -out $DIR/${KEY_PREFIX}.pem -outform pem
yubico-piv-tool -s $SLOT -a import-key -i $DIR/${KEY_PREFIX}.pem
ssh-keygen -e -f $DIR/${KEY_PREFIX}.pub -m PKCS8 > $DIR/${KEY_PREFIX}.pkcs8
yubico-piv-tool -a verify -P 123456 -a selfsign-certificate -s $SLOT -S "/CN=${PREFIX} key of $USER, slot $SLOT/" -i $DIR/${KEY_PREFIX}.pkcs8 -o ${SLOT}-cert.pem
yubico-piv-tool -a verify -P 123456 -a import-certificate -s $SLOT -i ${SLOT}-cert.pem
yubico-piv-tool -a status
echo "the current key is:"
ssh-keygen -D /usr/lib64/opensc-pkcs11.so
I can also use it to flash a 2nd key. I did a script because I wanted to do lots of test before deploying. New yubikey can generate bigger keys (new one do RSA 4096, afaik), but since I already own 5 of them (2 for ssh keys, 1 for 2FA, and 2 empty spare in case I lose one of the used one), maybe I should stop buying more.
If you go that road, do not forget also to change the management pin, listed as 123456 here. You can do it after, and canât remove it anyway (I tried, thatâs hardcoded in the ssh source and I wasnât willing to go deal with the OpenBSD crowd on that so I didnât even tried). Changing it would help in case of theft, but since most theft are done for the monetary value of the hardware more than the key, maybe you shouldnât sweat too much on it.
My code came from a few ressources that I did bookmark that could help:
There is a ton of doc out there, most being IMHO overly complicated since they usually deal with the GPG side, and kinda never explain the tradeoff made, have varying level of sophistication, and sometime requires to be updated.
Thatâs kinda overkill for ssh IMHO, and this doesnât really help people to realize that they could use a yubikey and just make sure their ssh keys do not fall in the wrong hands, because access to servers is a bigger target than personal GPG signatures by one or two order of magnitude.
Now, there is still issues, mostly around integration. For example, if I unplug the key, it should remove itself from the agent, but I have no way to do that easily (I did took a look at udev events, but nope). I need to load the key in the agent and type my pin on a console, while I would love to get it on first use (there is some option to do that for regular key, it doesnât work for pkcs11). I do not think the agent lock itself when I lock my screen. And the agent itself is open to any software I run, which is kinda not optimal, even if I guess I can write a SELinux policy for that (but the risk are too low for me to bother in practice).
For me, the GPG keys are equally important, since I encrypt my passwords file using my GPG key. The passwords file also contains my private keys for cryptocoins. I would probably be less paranoid if I didnât have crypto. That keys basically grants access to my private life.
My SSH keys grant access to lots of servers, probably around 5000 atm. Most of them allow access only from a whitelist of IPs, but some also listen on public. I should add some port knocking to them: Port knocking - ArchWiki
Nobody wants to be responsible for a breach, so from this point of view, the SSH keys should be better protected than the GPGs, yes. A person with access to my SSH keys could smash my career to bits. Get it? Smash âto 4096 bitsâ?
Is the pin digits only? That looks kind of easy to brutefordce, if somebody gets the hands on the physical yubi. I also am surrounded by lots of technical people that have the required knowledge to get my keys and steal my crypto. I donât doubt they are morally OK guys, but I still woudnât give anybody the chance to do that.
My keys currently have a passphrase (far bigger than 6 digits) so even if somebody gets their hands on the file, they will still have a very hard time getting the key. The only issue I find with this is that I am using gnome-keyring and seahorse for passphrase management so with complete access on the system, someone could in theory obtain the keys.
You highlighted a big issue with all hardware encryption systems. I am not ready to give my desktop up and use only one laptop⌠Right now, I have my private gpg keys on both, though both are configure in the same fashion (encrypted disk, only open source software, SELinux). I will continue to study these technologies till I make a final decision on the matter.
This makes it sound like the security enhancements of YubiKey are limited, since an attack on the agent could obtain the key even if the physical device is no longer present. Also, from what I understand, as long as the YubiKey is mounted, read rights on the system means access the key.
At the moment, TPM sounds better than YubiKey, since the private key never leaves the hardware, but that means always having my laptop in my backpack.
Yes, but the key lock itself after 10 attempts. Then you need another PIN, with limited attempts too before being locked for good. Then you can only reset it.
In my case, thatâs only ssh keys, so I can have more than 1, and change them, and identify systems more than person with them. And yeah, having multiple systems and coordinate the keys is a hard enough problem.
The agent canât do much if the key is not plugged. The keys I use for smartcard are yubikey nanos, they are made to stay in the USB port, and so are kinda small. The risk of removing them is that I would be more likely to lose them around than if it stay in the computer, thatâs why I remove them in specific case. I assume my flat and my employer office are safe enough, but I canât say that of various events, as I heard of laptop theft over the years.
In both cases, the key never leave the hardware. And the TPM is the same, someone has access to the session, that person can use the key, and you canât work around that, except by doing some fancy 2FA stuff (like key + password on recent enough openssh server). My issue with the key being usable when I am not near my computer is around either specific attacks like someone bypassing the lock screen due to some vulnerabilities like CVE-2010-0285, CVE-2007-3920, CVE-2015-8025 , CVE-2008-0887, CVE-2005-0078 , CVE-2012-0064 to list the few I remember.
Or just someone having access to the laptop somehow and waiting to use it when I am out to be stealth. But even if locked, I guess someone accessing my laptop could just add their keys or something similar anyway, so it would just stop a unprepared attacker, so again, I count this as ânice to haveâ.
Yes, but only if you want the key to be generated on the hardware. There is plenty of use where this is not required (like, generated outside of the smartcard, as I do now for backup purpose), so this could allow you to get a key for a discount on EBay or a friend if you need something for playing without spending too much money.
And Yubico support have always been great when there was security issues by replacing the key for free and letting me keep the old one. Thatâs how I ended having spare for my work, since I used them for 2FA and nothing smartcard related at that time.
@misc I use two Yubikey 4s to ssh my servers but on Silverblue I couldnât use it properly without layering. I tried it in my pet container but I could only ssh with root user. Do you have any experience with that?
No, I did layer it too. I suspect that a pet container would need pscd, and so would need to have access to USB devices, so that likely mean a privileged container and/or a way to communicate with a pscd running outside.
I did defer that problem for âlaterâ, as I did need a working system since using ssh is kinda required for my work
I have a different solution to the âbrowser needs to read everywhereâ problem.
I use 2 accounts⌠a) is the document keeper account, where all docs are written and kept. b) is the surfing account.
When I need to upload anything, I switch to the Document Keeper acc and copy over the file to the Surfing account. ( Document Keeper has write access to Surfing accountâs directories. )
So even though my Flatpak Brave browser can read the documents directory - no documents are kept there in the Surfing Account. And it cannot read outside of the Surfing account directories. And of course the Document Keeper never use the browser to go surfing.
Having to switch between accâs and entering passwords is a bit tedious, but this way I can keep the documents safe.
Separation of duties. Administrative control. Not a purely technical control. No need to meddle with SELinux.
Get it? Smash âto 4096 bitsâ? 