Oh you can still do that. The path changed to elf/cbfstool/[TREE]/cbfstool (replace [TREE] with the tree concerened). Note that since the switch to the libre RAM init code, mrc.bin is not included anymore
Yeah, that’s basically right. I believe flashprog is also included in libreboot, have a look in the elf/ directory. After that, it should work as expected
Yeah, that’s basically right. I believe flashprog is also included in libreboot, have a look in the elf/ directory. After that, it should work as expected
Thank you, kind person)) I installed it, but after installation my screen is too bright and this happens every time, so for now I will use the latest test version, it works well.
I have another question, please tell me how, in your opinion, I can edit grub.cgf correctly so as not to get an error with searching for disk “ahci1”
I installed the updated version 20240612 everything worked as you said. Checking nothing as in the previous instructions does not give anything, as you wrote: after switching to the libre RAM initialization code mrc.bin no longer turns on.
Now i need to edit grub.cfg because I get an error with searching for the achi1 disk
You can read about SELinux here or ACLs here. SELinux can be pretty complex if you’ve never used it, so make sure you understand it well. I believe it should be able to do what you want to achieve.
What do you mean by a file being displaced? Like do you want it to be unreadable, or unmodified, or just not deleted?
It’s not really possible to have a level of protection that would require more than sudo because with root access you bypass anything else.
You could put the files on an encrypted volume that uses a special password when it is mounted. Or you could use the chattr command to set special ext4 attributes that would make it unmodifiable (but could be removed with sudo). Or just record the file’s hash, and that way you know it hasn’t been modified later.
Like do you want it to be unreadable, or unmodified, or just not deleted?
I don’t necessariy care for any of those. They are ‘bonuses’ if you will. Though…:
Unreadable will be required for preventing recreating the file elsewhere.
Unmodifiable is not necessarily required. Maybe I would like to ‘append’ something to an existing file. But I’m fine either way. It should not be possible to delete some of the original data though.
What you describe in your post is a user who is not confident enough to manage their own machine with the CLI, and is afraid of misplacing files.
What you seem to not understand is that if you made the mv and cp commands require some sort of user interaction, nothing would ever work on the system, at least not in userspace if that’s the intent. No installer scripts, package managers, apps which use such commands…etc. Imagine implementing a rule like you describe, and then trying to copy/paste something in a GUI file manager, or organize music or photos.
So if you’re so afraid of moving something that needs not be moved, put some simple rules in place for yourself:
Don’t fuck around with anything outside of your homedir
Learn to reinstall system packages
Pretty simple. You also probably want to be on ZFS or BTRFS so you can undo your mistakes if you make them.
Isn’t literally ANY option here simpler than what you’re describing?
Thank you for your input! It has made me recognize that I should specify that I don’t want this to be system-wide; which was not clear from the post.
What you’re describe in your post is a user who is not confident enough to manage their own machine with the CLI, and is afraid of misplacing files.
I understand why I might have given off that impression. But no worries; I’m a (relatively) seasoned Linux user. I also have no qualms with CLI or whatsoever. It’s a specific set of files that I wish to ‘protect’.
I’ll straight up pose the question I asked someone else:
It seems I wasn’t clear as most people misunderstood me.
But, to give a very precise example; say
I had a folder called ~/some/folder.
It was on an encrypted drive.
And I had done additional work to encrypt the folder again.
And say, I used chattr, chmod or chown or similar utilities that remove access as long as one doesn’t have elevated privileges.
And say, I had done whatever (additional thing) mentioned in your comment.
Then, what prevents whosoever, to copy that file through cloning the complete disk?
Even if they’re not able to get past the password, it will be found on the cloned disk. SO, basically, I ask for some method that prevents the file to even be copied through a disk clone. I don’t care that it has three passwords protecting it. What I want is for the disk clone (or whatever sophisticated copy/mv/cut or whatsoever utility exists) to somehow fail while trying to attempt the action on the protected files.
Nothing can stop anyone anywhere from cloning a storage device. You can encrypt it however many times you want, but it can still be read at the block level.
I’m not sure where the paranoia lands or is focused towards, but there is no storage device that exists that can’t be copied, so if that’s your hangup, you should just accept that and move on. If someone has physical access to your drives, then can copy it, but whether they can decrypt it is up for debate.
As the saying goes: given enough time and effort, anything can be brute-forced.
What’s your end goal here? You try to keep files just on that one media without any options to make copies of them? Or maintain an image which has enforced files at their directories? And against what kind of scenarios?
ACLs and SELinux aren’t useful as they can be simply bypassed by using another installation and overriding those as root, same thing with copying. Only thing I can think of, up to a degree, is to use immutable media, like CD-R, where it’s physically impossible to move files once they’re in place and even that doesn’t prevent copying anything.
I want to prevent myself from reinstalling my system. The trick I came up with involved the use of files that couldn’t be disk cloned. However, if it’s far far easier to accomplish it through other means, then please feel free to enlighten me on this.
You try to keep files just on that one media without any options to make copies of them?
Yes.
Or maintain an image which has enforced files at their directories?
No, not necessarily.
And against what kind of scenarios?
Protecting myself from myself. That’s where the password requirement comes in: I can send a delayed message to myself that holds the password. The end result shouldn’t in the absolute sense prevent full access for always. Unlocking the protection should be possible and should require the involvement of the earlier mentioned password that is received through a delayed message. That way, those files can be accessed eventually, but only after I had intended to.
ACLs and SELinux aren’t useful as they can be simply bypassed by using another installation and overriding those as root
Excellent! I didn’t know this. Thank you for clarifying this for me!
Only thing I can think of, up to a degree, is to use immutable media, like CD-R, where it’s physically impossible to move files once they’re in place and even that doesn’t prevent copying anything.
The files should remain on the same disk that I run my OS from. So, unfortunately, this doesn’t quite help me. Thank you regardless!
I want to prevent myself from reinstalling my system.
Any even remotely normal file on disk doesn’t stop that, regardless of encryption, privileges, attributes or anything your running OS could do to the drive. If you erase partition table it’ll lose your ‘safety’ file too without any questions asked as on that point the installer doesn’t care (nor see/manage) on individual files on the medium. And this is exactly what ‘use this drive automatically for installation’ -option does on pretty much all of the installers I’ve seen.
Protecting myself from myself.
That’s what backups are for. If you want to block any random usb-stick installer from running you could set up a boot options on bios to exclude those and set up a bios password, but that only limits on if you can ‘accidently’ reinstall system from external media.
And neither of those has anything to do on read/copy protection for the files. If they contain sensitive enough data they should be encrypted (and backed up), but that’s a whole another problem than protecting the drive from accidental wipe. Any software based limitation concerning your files falls apart immediately (excluding reading the data if it’s encrypted) when you boot another system from external media or other hard drive as whatever solution you’re using to protect them is no longer running.
Unless you give up the system management to someone else (root passwords, bios password and settings…) who can keep you from shooting yourself on the foot, there’s nothing that could get you what you want. Maybe some cloud-based filesystem from Amazon with immutable copies could achieve that, but it’s not really practical on any level, financial very much included. And even with that (if it’s even possible in the first place, I’m not sure) if you’re the one holding all the keys and passwords, the whole system is on your mercy anyways.
So the real solution is to back up your files, verify regularly that backups work and learn not to break your things.
It sounds like you’re actually more concerned about the data in the files not being able to ‘pop up’ elsewhere, rather than the files themselves. In thus case I’d suggest simply encrypting them, probably using gpg. That’ll let you set a password that is distinct from the one used for sudo or similar.
You should also be using full disk encryption to reduce the risk of a temporary file being exposed, or even overwritten sectors/pages being available to an attacker.
I’ve failed tremendously in making my demands come across :P .
Uhmm…, what you propose with gpg definitely solves one part of the puzzle.
But, if I understood correctly, it doesn’t help to prevent a disk clone from getting hold of the files.
Yes, the files are encrypted, but that’s not sufficient for my needs by itself. If the files would somehow destroy or corrupt themselves on a disk clone (or something to that effect), I would have acquired what I’m seeking.
Nothing can prevent a disk clone cloning the data, and there’s no way to make something happen when a disk is cloned as you’re not in control of the process.
If you wish to mask the existence of the files, use either full disk encryption, in which case cloning the disk doesn’t reveal the existence of the files without the decrypt password, or use a file based encrypted partition such as veracrypt in which case the cloner would just see a single encrypted blob rather than your file names.
Ultimately encrypting the files with gpg means they have already effectively ‘destroyed or corrupted’ themselves when cloned. If you don’t want to reveal the filenames, just call them something else.
If you could be a bit more specific about your threat model people may have better ideas to help.
If you could be a bit more specific about your threat model people may have better ideas to help.
Threat model is me protecting myself from myself.
Incoming XY problem.
I want to prevent myself from reinstalling my system. The trick I came up with involved the use of files that couldn’t be disk cloned. However, if it’s far far easier to accomplish it through other means, then please feel free to enlighten me on this.
Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.
Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.
If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.
Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.
Premises:
Very important files on disk (somehow) protected from copy/mv/clone whatever.
Reinstalling my OS wipes the disk.
Therefore, I would lose those very important files if I were to attempt a wipe. If said files are important enough for me to reconsider wiping, then the act of protecting them from copy/mv/clone has fulfilled its job of preventing me from reinstalling the OS.
Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.
I understand.
If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.
Very interesting. A couple of questions:
Is it possible to only protect a set of files through this? So not the entire disk?
This seems like a very complicated way to achieve your goal! It sounds like sitting yourself down and giving you a stern talking to might be a beter aporoach.
Having said that, if you have these very important files that you don’t want to lose, please make sure they’re backed up somewhere off of your machine. Storage fails, and it’s a horrible feeling losing something important. Unfortunately doing so would defeat the approach you’re thinking of.
This might be a case of needing to reframe the question to get to the cause of the issue, and then solve that. So, why do you want to make it hard to reinstall your machine? Is it the amount of time you spend on it, the chance of screwing it up, needing it working, has it become a compulsion or something else? Maybe if we can get to the root of the issue we can find a solution.
With regard to TPM, it’s basically just a key store, so you can use it fir anything really, althought it’s normally used by generating a TPM key and using it to encrypt the key that’s actually used to encrypt your data, storing the encrypted key with the OS. Just reinstalling won’t wipe the TPM, but unless you made an effort to save the encrypted key it’ll be gone. Given your problem statement above it just adds to the data you’d need to save, which isn’t helpful.
This seems like a very complicated way to achieve your goal! It sounds like sitting yourself down and giving you a stern talking to might be a beter aporoach.
You’re probably right. But, it ensures a surefire method if accomplished.
Having said that, if you have these very important files that you don’t want to lose, please make sure they’re backed up somewhere off of your machine. Storage fails, and it’s a horrible feeling losing something important. Unfortunately doing so would defeat the approach you’re thinking of.
Thank you for your concerns!
This might be a case of needing to reframe the question to get to the cause of the issue, and then solve that.
Makes sense.
So, why do you want to make it hard to reinstall your machine?
I want to set it up in a particular way to ensure maximum productivity. But I’m afraid that I’ll not go through with it (as has happened a lot in the past). Thus, making it impossible to reinstall should enable me to go through. As I wouldn’t have any other choice.
Is it the amount of time you spend on it
The amount of time spent unproductively. Yes.
the chance of screwing it up
Nope. I haven’t had a serious breakage since over one and a half years. I think I’m managing splendidly.
needing it working
Don’t really have particular problems related to keeping my system up and running.
has it become a compulsion or something else?
Not sure what you meant with this.
Maybe if we can get to the root of the issue we can find a solution.
I believe I touched upon this earlier in this comment. I just want to be very productive.
With regard to TPM, it’s basically just a key store, so you can use it fir anything really, althought it’s normally used by generating a TPM key and using it to encrypt the key that’s actually used to encrypt your data, storing the encrypted key with the OS. Just reinstalling won’t wipe the TPM, but unless you made an effort to save the encrypted key it’ll be gone. Given your problem statement above it just adds to the data you’d need to save, which isn’t helpful.
Uhmm…, I feel as if I should properly read up on this. Have you got any pointers you would recommend?
I think I understand where you’re coming from with the desired to be productive and not reinstall. I think I’ve been there too! One thing that I can suggest, if you do have the time, is to learn a system like Ansible and use it to setup and configure your machine. The discipline of keeping all of the config as source rather than making ad-hoc changes reduces the chance of thinking you’ll make just one little change and breaking something, and, if something does go wrong, you can get back to your working configuration quickly.
Bearing in mind that there really isn’t anything you can do to stop yourself if you’re really determined to not lose the data, because if you can read it at any time you can back it up, the closest you are likely to come is something like creating new key with GPG then using the TPM to wrap your secret key and deleting the original. That way the key is only usable on that specific machine. Then use the key-pair to encrypt your ‘guard’ files. You can still decrypt them because you have the wrapped secret keys and you’re on the same machine, but if you wipe the drive and lose those keys the data is gone. The TPM wrapping prevents you from taking the keys to a different machine to decrypt your data.
Having said all of that, this still doesn’t help if you just clone the disk as all of the data, including the wrapped key and the encrypted files will be cloned. The one difference there is that the serial number of the hard drive will be different. Maybe you could use that, combined with a passphrase as the passphrase for your GPG key, but we’re getting into pretty esoteric territory here. So you could generate a secret key with a command like:
Where /dev/sdb is the device your root partition is on. zenity is a handy utility for displaying dialogs, there are others available. In this use it just prompts for a passsword. We then concatenate the drive serial number from lsblk with the password you entered and hash the result. The hashing is really only a convenient way to mix the two without worrying about the newline lsblk spits out. Don’t record the result of this command, but use it to set the passphrase on your new GPG key. Wrapping the secret key in the manner the article above suggests is a nice extra step to make it harder to move the drive to another machine or mess around in that sort of way, but not strictly necessary as that wasn’t in the scope of your original question.
Now you can encrypt your file with: gpg -e -r <your key name> <your file>'. That will produce an encrypted version of <your file>called<your file>.gpg. To decrypt the file you can get gpg` to use the hashing command from above to get the passphrase with something like:
Once you’ve tested that you can decrypt the file successfully you can remove the original, plaintext, file. Your data is now encrypted with a key that is secured with a passphrase made of a string you know and the serial number of your disk and optionally wrapped with a key from the TPM that is tied to your physical machine. If you change the disk or the machine the data is irretrievable (ignoring the caveats discussed above). I think that’s about as close to your original goal as you can get. It’s rough around the edges, and I’m not sure I’d trust my data to it, but I believe it’ll work. If you do something like this, please test it thoroughly, I can’t guarantee it!
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.