@scottalanmiller said in Linux: Creating a Filesystem:
@thwr said in Linux: Creating a Filesystem:
Good article, just missing two things here...
If you check the main article, you can see placeholders for a lot of where content will be. Memory management doesn't have a ToC created yet, but it will be coming.
great, thanks
@scottalanmiller said in Linux: Creating a Filesystem:
@thwr said in Linux: Creating a Filesystem:
Good article, just missing two things here: ext2 or even FAT32/vfat on /boot is still quite common, mkswap is also important
mkswap will be covered separately. It's not quite a filesystem, exactly. EXT2 and vFAT have been dropped from use on /boot on current generation systems. That's a vestige now. Was still common in the RHEL 5 / CentOS 5 era, but has been some time now.
You are right, but a popular distro using vfat on /boot is Debian-based Raspbian for example.
Good article, just missing two things here: ext2 or even FAT32/vfat on /boot is still quite common, mkswap is also important
@scottalanmiller said in What Are You Doing Right Now:
We are out of food around the house, but there are enough ingredients for making chocolate chip cookies. So that is the food for today. This is what happens on travel days.
So you still keep up to the American Way of Life? (SCNR)
BTW: Chocolate chip cookies would be a great ML swag. Need my postal address? 
There's a silver wedding anniversary within the family this weekend. Will be great, most probably not like The Walking Dead.
@NattNatt said in Random Thread - Anything Goes:
@thwr so, that'd be a closed port that causes that? So would that be a Reject?
Bingo!
@NattNatt Trust me, IT is learning until you leave the building - with your feet first. Damn, another German saying 
@scottalanmiller There's a german slang term, "Klickibunti". In case I need to translate that, it's like "Clicking on shining colorful GUIs". Maybe that question was in fact a bit hard for the targeted audience (SMB) - don't get me wrong on this please
@scottalanmiller TBH, the mods are doing a good job over there. Took a few weeks for this questions to become active while others I've submitted later became active after just a few hours:
Tagged it as a hard question, that's not exactly common knowledge. Taken 9 times as of today, but there's no mentioning about the number of times it was answered correctly.
@NattNatt Thats probably because users are able to submit questions, there are nearly 1,000 as of today. Submitted six of them myself.
As for the range of topics within the questions: IT is very broad as of today - no more "Are you an IBM MVS or HP3000/9000 guy?" - just thought that the above "which" command is pretty basic knowledge, even for non-kernel hackers.
@scottalanmiller said in Kickstart with LUKS:
@thwr said in Kickstart with LUKS:
@thwr said in Kickstart with LUKS:
But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.
Ah, sorry, misunderstood your posting in the first place. Well, that's chicken-egg. You can either have it decrypt automatically or not. If going for automatic decryption, we have to make sure the machine can't decrypt e.g. when it gets stolen or sold.
For this, storing the key on the host alone, even with TPM, may not be enough (don't know enough about TPM at this point. Sealing to system state seems quite safe, but...). Thus, we need to bring in another factor. Let's call it "location awareness", e.g. pulling the actual key from the network and TPM stores just something to authenticate against the "key server". Server offsite -> no decryption.
Past boot, it is up to you to secure the server by traditional means. Strong passwords, no or strongly secured RS232 TTY and so on.
Exactly, something externally has to trust that the system is where it is supposed to be physically so that it will release the key. We considered using this but decided that security trumped downtime and kept the system requiring human intervention and just accepted large downtimes in the event of a reboot.
Agree, downtime due to a misconfiguration, some failure on the network or the key server would be an issue. What if we look at some back approach: If some removeable storage with a key is present at boot, LUKS will use this key. Otherwise, it tries to pull it from the key server as described above? Should be pretty solid and a backup is in place (key on USB stick) in case something goes south.
This surely is an approach for environments requiring a very high level of security, but I like the idea.
@thwr said in Kickstart with LUKS:
But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.
Ah, sorry, misunderstood your posting in the first place. Well, that's chicken-egg. You can either have it decrypt automatically or not. If going for automatic decryption, we have to make sure the machine can't decrypt e.g. when it gets stolen or sold.
For this, storing the key on the host alone, even with TPM, may not be enough (don't know enough about TPM at this point. Sealing to system state seems quite safe, but...). Thus, we need to bring in another factor. Let's call it "location awareness", e.g. pulling the actual key from the network and TPM stores just something to authenticate against the "key server". Server offsite -> no decryption.
Past boot, it is up to you to secure the server by traditional means. Strong passwords, no or strongly secured RS232 TTY and so on.
@scottalanmiller said in Kickstart with LUKS:
@thwr I think that storing on the TPM is good if the goal is only to prevent the drives from walking and not the server. You could do that with SD card or something too, but TPM is obviously better (unless the server gets damaged and you lose all of your data.)
But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.
You would need to reset TPM as you would reset your HDD. In fact, it should be good enough to reset the TPM. You could store the passphrase / key additionally on some secure place outside of the individual host - better safe than sorry.
@scottalanmiller said in Kickstart with LUKS:
What I had proposed to a bank some years ago was having a system by which a decryption script would call out to a service on the LAN and request the passphrase. It's not nearly as secure as a person, but you could put a lot of security in place if needed (make it check with a person via email before releasing it, only do it for planned reboots or at certain times, etc.) This way if a server is stolen, it's totally encrypted. You would need to have two, unrelated breaches, in order to access the encrypted drives. Could still happen, but it would eliminate the human break point while adding a technical one. But it would allow systems to be rebooted automatically while keeping them encrypted.
My proposal is basically the same, just adding TPM as a secure element to the equation. Using TPM, we can be sure that the machine pulling the key from LAN is actually ours / a known one.
We like to see the best possible security approach at work as a combination of knowing (e.g. passwords, PINs), being (e.g. biometrics or TPM here) and owning (smartcards or RSA tokens for example). The more factors you bring in, the better.
Just did some more reading. From the tpm-luks site:
D. Sealing your NVRAM area to PCR state
Sealing means binding the TPM NVRAM data to the state of your machine. Using sealing, you can require any arbitrary software to have run and recorded its state in the TPM before your LUKS secret would be released from the TPM chip. The usual use case would be to boot using a TPM-aware bootloader which records the kernel and initramfs you've booted. This would prevent your LUKS secret from being retrieved from the TPM chip if the machine was booted from any other media or configuration."
This would at least prevent someone grabbing the key from owning the hardware alone. I guess we are still facing the chicken-egg-dilemma here. But, what if we don't place the actual key in TPM but to an external webservice maybe?
This way, we don't have the actual key on the hardware itself and the webservice can only be queried during boot. This would require some hacking in tpm-luks, but the longer I think about it... could be a valid solution.
Conn: Works only on-site, so not a good solution for notebooks. You will also need some kind of access to your network (NIC drivers and TCP/IP stack).
Edit: Some more reading on TPM and LUKS: http://resources.infosecinstitute.com/linux-tpm-encryption-initializing-and-using-the-tpm/
@Jason Not yet. Problem is, there's some confidential data going over that wire. Sure, already encrypted on OSI-7, but I don't feel comfortable using a solution in this context I don't know. Would rather like to stick to IPsec (preferred) or OpenVPN.
@Jason said in pfSense slow site-to-site VPN:
OpenVPN is normally much slower..
No preference for OpenVPN, tried both, IPsec being just 1MB/s faster. Oddly, latency is still great while throughput is low. Both lines are sync 1GB/s, just some fiber and roughly 4 km / 2.5 miles in between. Next to no reflections on the fibre.
Async lines are a known problem especially in OpenVPN, but that shouldn't be the case
@scottalanmiller oh, that was just one of these "what if" moments. Never played with TPM, but used to play with smartcards and their "secure elements" a bit.
Just took a look into TPM. From https://en.wikipedia.org/wiki/Trusted_Platform_Module: "[...] Trusted Platform Module [...] also includes capabilities such as [...] sealed storage [...]".
Digging a bit deeper, I found this: LUKS support for storing keys in TPM NVRAM https://github.com/shpedoikal/tpm-luks
Looks promising
