Decrypt file for specific session in CentOS 7

I am looking for a way to encrypt my file that can be decrypted for the current terminal session. The moment we exit the session, it gets encrypted again.

A use case for this scenario would be: Let's say if someone wants to gain access to the file by rebooting the system forcefully via hypervisor and change root password to gain access, if the file stays encrypted, the attempt would be futile.

So far, I know ways to encrypt the file or the entire filesystem can be decrypted and would stay that way until it is encrypted again. I am looking for a temporary decryption. I even found ways to keep the content of the file encrypted till a passphrase is provided to make it readable rather than gibberish. That doesn't help either as the file is executable.

The idea is to run this file remotely on a system to capture traffic on a public hypervisor. So if someone does try to break in, they won't be able to do it.

I have already enabled grub password, it is not a viable solution due to a few anomalies faced in the process

Any other ideas or suggestions would be highly appreciated.

I think you may be confused about how disk encryption works.

So far, I know ways to encrypt the file or the entire filesystem can be decrypted and would stay that way until it is encrypted again. I am looking for a temporary decryption.

When you use full-disk encryption with dm-crypt/luks or veracrypt, the data on the disk remain encrypted at all times. Typically, only the bootsector is unencrypted, leaving you vulnerable to attacks at or before boot, but there are more advanced configuration steps that can be taken in an attempt to mitigate this. Additionally, typically the crypt-header is typically left on the disk, because really, how bad is the password, how sensitive is the data, and who are you ultimately afraid of?

Here's a great thread on brute-forcing dm-crypt/luks headers: https://news.ycombinator.com/item?id=21791785 . There's a lot of math that goes way over my head, and I'm definitely deviating from your question, but here's a nice quote that made me both disappointed (as I have some encrypted containers I would like to brute-force) and comforted (because nobody with any sense wants to live in a world where the security of encryption technology cannot be trusted. That debate happened in the 90's and the technologically illiterate authoritarians were uncomfortably close to winning.):

If you can devote 1200 CPU cores to this project, you have a 50/50 shot at cracking the password by the time the universe is twice as old as it is now.

Basically, if you want into a dm-crypt/luks device, evil maid or $5 wrench. If nobody remembers the password anymore, it's essentially random data. Even with quantum computers, if the password and hash algorithms are good enough, nobody is getting in within our lifetime.

Back to your question: Under typical system configuration, other than the boot sector and the swap, the data on the disk remains encrypted at all times. You provide the encryption key at boot, the key is held in memory, all encryption takes place before writing to the disk, and all decryption takes place on the fly as you read the disk. All of the filesystem information is kept in memory, absolutely no unencrypted data should be on the disk... Other than the swap, which you may want to do something about.

A use case for this scenario would be: Let's say if someone wants to gain access to the file by rebooting the system forcefully via hypervisor and change root password to gain access, if the file stays encrypted, the attempt would be futile.

So again, I think you might be confused about how encryption works, but also, there are a lot of different situation-specific considerations to be made. The question I would ask is, are you at all concerned about another person on this device that also has root access discovering the file while it is in use? Are you at all concerned that that another person that has root access would discover the existence of an unfamiliar encrypted container that they're not familiar with? If so, the following solution is not for you.

With veracrypt and preferably dm-crypt/luks, not only can you encrypt entire disks or partitions, you can also create encrypted containers. You can mount these containers when you open your session and unmount them before you close the session. Unfortunately, when they are mounted, another user of the system with root access would still be able to access them. On Unix, root is god. Could you imagine the horror of being an administrator of a device and discovering an inaccessible partition?

I hope that helps a bit. You have a lot of options, but I think you maybe need some greater clarity on what it is you are trying to do. You've posted this with the "luks" tag, so you're heading in the correct direction, property configured dm-crypt/luks is the strongest encryption currently available. I advise you to read more and gain a better understanding of encryption.

https://blog.canadianwebhosting.com/how-to-create-an-encrypted-container/

https://linux.die.net/man/8/cryptsetup

https://wiki.archlinux.org/index.php/Dm-crypt

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption

https://wiki.gentoo.org/wiki/Dm-crypt

https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html

Also, on the topic of rebooting the system forcefully via hypervisor: This is an interesting subject, because an attacker who had that level of access to the hypervisor could also act as an evil maid, poisoning your boot and intercepting your encryption password. They could do that, and also pretty much anything they wanted. This is why the locations of AWS datacenters are not publicly available, the idea is that they are secure. You have to trust the host.

The idea is to run this file remotely on a system to capture traffic on a public hypervisor. So if someone does try to break in, they won't be able to do it.

Again, I think you may be confused. When you refer to "public hypervisor", do you mean that you're intending to run this on the baremetal hypervisor of a machine that publicly hosts VMs? Otherwise, I can see two things that you are potentially trying to do: One is that you have a hosted virtual machine, are attempting to sniff all of the traffic on the other virtual machines hosted by the hypervisor, and are attempting to conceal this by encrypting the sniffing software. The other is that you have a hosted virtual machine, are attempting to secure it by sniffing the traffic, yet are concerned by an evil maid attack on the root password.

In all of these situations, I would advise you to reconsider some of or all of your hypotheses.

The only other possible interpretation I could come up with is that perhaps you have pwned this box and want to run a sniffer on it without it being detected? But come on now, if you pwned this box and you're coming and going as you please without getting caught, you think they're going to notice the sniffer?