this post was submitted on 22 Jun 2024
37 points (93.0% liked)

Linux

48183 readers
1450 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

(More) Specifics:

  • Undoing the protection should include filling in a password.
  • The password should be different from the one used with sudo or any other passwords that are used for acquiring elevated privileges.

All (possible) solutions and suggestions are welcome! Thanks in advance!

Edit: Perhaps additional specifications:

  • With 'displace‘, I mean anything involving that resembles the result of mv, cp (move, cut, copy) or whatsoever. The files should remain in their previously assigned locations/places and should not be able to 'pop up' anywhere.
  • I require for the files to be unreadable.
  • I don't care if it's modifiable or not.
  • I don't require this for my whole system! Only for a specific set of files.
top 50 comments
sorted by: hot top controversial new old
[–] notabot@lemm.ee 12 points 4 months ago (1 children)

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.

[–] poki@discuss.online 1 points 4 months ago (1 children)

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.

[–] notabot@lemm.ee 5 points 4 months ago (6 children)

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.

load more comments (6 replies)
[–] rotopenguin@infosec.pub 8 points 4 months ago (1 children)

If you don't want files to be accessible by you, then have another user own them.

If you don't want files to be accessible by root, then don't have them at all.

load more comments (1 replies)
[–] IsoKiero@sopuli.xyz 8 points 4 months ago (1 children)

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.

[–] poki@discuss.online 2 points 4 months ago (1 children)

What’s your end goal here?

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.

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!

[–] IsoKiero@sopuli.xyz 1 points 4 months ago

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.

[–] bjoern_tantau@swg-empire.de 6 points 4 months ago (1 children)

What do you mean with "displace"?

[–] poki@discuss.online 1 points 4 months ago

'Move'; this includes copying, cutting or what have you. It should remain in the assigned directory/location. I'll include this remark. Thank you!

[–] BestBouclettes@jlai.lu 6 points 4 months ago (1 children)

I guess you can use ACLs depending on your filesystem, or SELinux user contexts.

[–] poki@discuss.online 2 points 4 months ago (1 children)

Seems interesting. Got any sources to read up on? Thanks in advance!

[–] BestBouclettes@jlai.lu 2 points 4 months ago

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.

[–] hedgehog@ttrpg.network 5 points 4 months ago (3 children)

It sounds like you want these files to be encrypted.

Someone already suggested encrypting them with GPG, but maybe you want the files themselves to also be isolated, even while their data is encrypted. In that case, consider an encrypted volume. I assume you’re familiar with LUKS - you can encrypt a partition with a different password and disable auto-mount pretty easily. But if you’d rather use a file-based volume, then check out VeraCrypt - it’s a FOSS-ish [1], cross-platform tool that provides this capability. The official documentation is very Windows-focused - the ArchLinux wiki article is a pretty useful Linux focused alternative.

Normal operation is that you use a file to store the volume, which can be “dynamic” with a max size or can be statically sized (you can also directly encrypt a disk partition, but you could do that with LUKS, too). Then, before you can access the files - read or write - you have to enter the password, supply the encryption key, etc., in order to unlock it.

Someone without the password but with permission to modify the file will be capable of corrupting it (which would prevent you from accessing every protected file), but unless they somehow got access to the password they wouldn’t be able to view or modify the protected files.

The big advantage over LUKS is ease of creating/mounting file-based volumes and portability. If you’re concerned about another user deleting your encrypted volume, then you can easily back it up without decrypting it. You can easily load and access it on other systems, too - there are official, stable apps on Windows and Mac, though you’ll need admin access to run them. On Android and iOS options are a bit more slim - EDS on Android and Disk Decipher on iOS. If you’re copying a volume to a Linux system without VeraCrypt installed, you’ll likely still be able to mount it, as dm-crypt has support for VeraCrypt volumes.

  • 1 - It’s based on TrueCrypt, which has some less free restrictions, e.g., c. Phrase "Based on TrueCrypt, freely available at http://www.truecrypt.org/" must be displayed by Your Product (if technically feasible) and contained in its documentation.”
load more comments (3 replies)
[–] frankfurt_schoolgirl@hexbear.net 5 points 4 months ago (1 children)

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.

[–] poki@discuss.online 1 points 4 months ago

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.
  • Not deleted is a must as well.
[–] possiblylinux127@lemmy.zip 5 points 4 months ago* (last edited 4 months ago) (3 children)

What are you trying to do? Why don't you just use full disk encryption?

load more comments (3 replies)
[–] trigg@lemmy.world 4 points 4 months ago* (last edited 4 months ago) (1 children)

I'm not sure I'm fully understanding. Are you wanting files which can be read but never copied?

Scratch that, i missed a line. So simply files stored but not user readable.

[–] poki@discuss.online 1 points 4 months ago* (last edited 4 months ago)

Scratch that, i missed a line. So simply files stored but not user readable.

But also not being able to be copied; even through a disk clone.

[–] ssm@lemmy.sdf.org 2 points 4 months ago* (last edited 4 months ago) (1 children)

Just make the file root owned and readable by no one. An unreadable file can't be copied. You can use chattr to add some flags like immutability if you desire (shouldn't really need to). Use a command like find /some/path -type f -exec chattr whatever {} \; if you need to do this recursively. Root account should need a password, and should (hopefully) not be accessable with an unprivileged user's password through sudo/doas, but on its own account with it's own password using su or login.

Note that without encrypting the file, this does not protect you from someone just grabbing your storage device and mounting it with root permissions and then they can do whatever they want with your data. It also doesn't protect you if someone gets root access to your device through other remote means. If you want to encrypt the file, use something like openssl some-cipher -k 'your password' -in file -out file.cipher_ext. If you want to encrypt multiple files, put them in a tarball and encrypt the tarball. You can again also use find with openssl to encrypt/decrypt recursively if you don't want to use a tarball, which may be better with ciphers like blowfish that aren't secure at large file sizes; but if you do that, you expose your encrypted file system structure to attackers.

I am not a fan of full disk encryption, because it usually means leaving all your data decrypted during runtime with how most people use it. If you only decrypt a block device when you need to, there's nothing wrong with that, and can work as an alternative to encrypting a tarball.

[–] poki@discuss.online 1 points 4 months ago

Definitely one of the better answers I've received so far. Thank you for that. However, I feel as if the following part reveals that it's not as 'protected' as I'd like:

It also doesn’t protect you if someone gets root access to your device through other remote means.

Though, at this point, I've somewhat accepted that I'm seeking a software solution for a hardware problem. Hence, the impossibility of my query... I hope I'm wrong and perhaps you can point me towards the solution I'm seeking. However, if that's not the case, then I would like you to know that I appreciate your comment. Thank you.

[–] utopiah@lemmy.ml 1 points 4 months ago (1 children)
[–] poki@discuss.online 1 points 4 months ago* (last edited 4 months ago)

😅. It's a requirement that the data stays on the same drive that I run my system from.

[–] just_another_person@lemmy.world 0 points 4 months ago (1 children)

If you have these types of issues, just move to an immutable distro.

[–] poki@discuss.online 1 points 4 months ago (1 children)

Who says I'm not already :P . Got any ideas on how this might be able to specifically solve the problem at hand?

[–] just_another_person@lemmy.world 4 points 4 months ago* (last edited 4 months ago) (7 children)

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?

load more comments (7 replies)
load more comments
view more: next ›