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.”

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.

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

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.

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.

Looks like a USB stick.

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.