[thusi02]

Hi,

I guess what I am trying to do is LOCK A DOOR and THROW away the keys. Reason is I would like to encrypt a HIGH security file where many others have access to it on the server. I would like to encrypt it and put it in a cron for it to run daily. However, I would not like anyone to decrypt the file or view its contents as lots of passwords etc must reside there. So has anyone come across this problem and if so what is the approach you took.

Cheers,
Nathan.

[kakariko81280]

I suspect encryption is not the right thing to use here. You're basically moving the problem from people being able to access the file being executed to people being able to access the key file that needs to be used to decrypt the file before it can be run.

I'd suggest creating a separate user to run the file. Change the permissions so only that user can read and execute the file.

If that's not enough you can do more, but it would help if you could let us know what kind of file it is and what it does.

Let us know how you get on,

Chris...

[thusi02]

Hi kakariko81280,

You see the problem is that many of the users have sudo access on the machine. Also most of them are involved in the project as well. The problem is that we need to make a database connection to grab some of the data to populate our internal database. However, this db requires us to put our personal username/passwords to authenticate. Meaning we do not get a role account on the database. Thus as you can see, we do not want to put our account information into the script in clear text. As also most of the members have sudo access and will be aware of the process. So I would like to somehow put this account information in the script and encrypt it somehow so that others this includes the team members cannot read the file. However we should be able to remake the file to put in another person credential if one leaves the team. The main fact is that no one should be able to decrypt the file to read it in anyway as the file will contain the password.

Any thoughts?
Thank you for your time and effort.
Cheers,

Nathan.

[devils casper]

You can use openssl to encrypt files.
To encrypt a file:

openssl des3 -salt -in infile.txt -out encryptedfile.txt

To decrypt the file:

openssl des3 -d -salt -in encryptedfile.txt -out normalfile.txt

Do not specify the same file as input and output on encryption. I have noticed weird effects on OS X (it eats the file). Remove the -in * stuff if you want to pipe data into it (e.g. a tarred folder). Omit the -out * stuff if you want it to pipe data out on STDOUT.

[thusi02]

Hi devils_casper,

Thank you for your reply. However, solution does not work as well. I have looked into this however, since there is a way to decrypt the file this will not work. Basically I want a one way ticket. I want to be able to encrypt the file and have it execute. However, I do not want there to be anyway of decrypting the file. So I want a member of the team to put their password into the file and encrypt the file and be safe that no one else is going to come along that has sudo access on the system to be able to decrypt the file. This is where the dilemma is.

Any thoughts?

Cheers,
Nathan.

[devils casper]

So I want a member of the team to put their password into the file and encrypt the file and be safe that no one else is going to come along that has sudo access on the system to be able to decrypt the file. This is where the dilemma is.

Whenever you encrypt any file with openssl, it asks for password. You can assing any password. No body can decrypt that file, not even root user unless you disclose the password assigned during encryption.

[kakariko81280]

I don't want to be pessimistic, but I don't think there is a way to achieve exactly what you are after.

An encrypted script would require decryption before it could be run. Because you want the script to be run by cron you need to put everything needed to decrypt the script on the server.

You can't prevent a root user who is aware of the process from performing the same steps as the cron job to recover the plain text and therefore the passwords you are trying to protect.

Can you set up a separate user on the database that only has access to the data that will be pulled by the script? If so then it shouldn't matter if your users can use that login because they will only be able to access data that is made available on a daily basis anyway.

Another option would be to write a simple application instead of a script. The compilation process would obfuscate the steps somewhat, but it depends on how good your users are at analysing compiled programs and what tools they have available.

Let us know how you get on,

Chris...

[thusi02]

Hi devils_casper,

Thank you for clarifying that. That helps quite a bit.

Follow up question: So now that I encrypted this python library file. When I import it into a python script it complains about the encoding type. Do you by chance know how to get around this? Do I have to provide the decryption password in the script which kinda defeats the purpose again. Please let me know.

Thank you
Regards,
Nathan.

[GreyGrey]

I'm no expert on this, but the point of encryption is to be able to decrypt.

If you don't want specific users to be able to decrypt the file because you fear they are going to learn other peoples passwords that are stored in the file, but at the same time you want a program to be able to write data to the file, you still have to store the key somewhere because the program will need to decrypt the file in order to write and read meaningful data to it. Like someone said, you can pull the users' permissions to the file, and then write an su program to modify the encrypted file, but you'd then have to pull the users' sudo access to avoid them circumventing the permissions you set up.

Anyway the point is your problem lies in your users' root access

[bigtomrodney]

Surely you can be more discriminating in the /etc/sudoers file? Grant users only the root permission for what they need?