Running Command in Cron without giving away password

DJOtaku · 11-13-2009, 10:13 AM

Using the trivial example I found online of

Code:

0/5 * * * * wget -O /tmp/web.tmp --user=foo \
                               --password=SeCuRePwD \
                               http://www.site.com/

I know I can read in the password from a file. But that still leaves it vulnerable to anyone who is able to log in as the owner of that file or root. How can I read in the password from somewhere shadowed or hashed?

Thank you!

choogendyk · 11-13-2009, 06:29 PM

The thing is that you are passing them over the net in clear text. It's not https. So anyone can snoop that. On the other hand, the crontab files are only readable by root, or by the user whose crontab they are. So, if you get into the system as root or that user, you've got it anyway. Therefore, I'm not sure what you gain by trying to obfuscate it.

If the remote web site would allow the use of certificates, you could do that. Restricted certificates are a good way of doing that sort of thing if you can.

DJOtaku · 11-16-2009, 06:30 AM

I think by using the example, I caused you to miss the point. The example is trivial - doesn't matter that it's not https. It could be any program that needs a username and password that needs to be obfuscated.

choogendyk · 11-16-2009, 07:29 AM

And, certificates are the answer. I've seen passwords exposed in scripts many times. Another example is using Expect, logging into another system and interacting with a menu to do something -- passwords exposed. You can control access privileges to the script. You can encrypt the transaction. Or, you can use certificates. I believe when you login, the login procedure grabs control of the terminal and asks for the password. I don't think you can bypass that. It's a security issue. If someone else can give a more authoritative answer on that particular point, I would welcome it.

DJOtaku · 11-16-2009, 07:32 AM

Even if it's a program running on the same computer? (Instead of over the web)

choogendyk · 11-16-2009, 06:20 PM

You have to be more specific. Too much depends on what you are doing. But, typically, if you are going through a standard login, you can't divert it. If you have a root cron, it can su to a more restricted user without supplying a password (it's root, so it can do that). I have backup scripts that run as root and su to the backup user which uses a restricted certificate to connect to the tape server. As I look at some of these different things, I find `echo -e "user\npass" | ftp localhost` as an example on http://en.wikipedia.org/wiki/Redirec...28computing%29, and I think, ok, how about replacing "pass" with "`cat /secure/file/x`". Might work. Then again, since your trivial example at the top is a wget to a web page, the same approach may work there. But, if you try to do a script that ssh's somewhere, and try to embed the password in the script, and then run it from the terminal, I believe it will come back at you at the terminal asking for a password.

Bottom line is to try what you want to do and see what happens.

I would always ask, though, what are you buying in security? If a crontab is only readable by root and the user it belongs to, and the password file you create is only readable by root and the user it belongs to, then what have you gained?

Check out http://sial.org/howto/openssh/publickey-auth/, and scroll down to "Key Access Limits". Also, do a man page on sshd(8). That will give you the format for access limits. I've created automatic logins that will only work for one specific command. It's hard to beat that for security other than by locking your server in a safe with no wires in or out. ;-)

DJOtaku · 11-17-2009, 06:07 AM

Ok, this web page is the reason why the fact that only root and the user can see their own crontabs isn't enough. http://blog.rootshell.be/2008/04/01/crontab-security/

Here's the specific worrying part:

Quote:

When an execution time is reached, the crond spawns a new process (shell) and executes the scheduled command with the user privilege. By default, the new shell and sub-processes are all visible to all users using the ps command:

$ ps axwwwo "login,command" | more

so let's say I had a program - say payroll or something local to the machine. It requires a username and password and there's something automated I want to do. What the page suggests is good:

Quote:

Store your password in a safe file in your home directory and schedule commands like:

0/5 * * * * wget -O /tmp/web.tmp --user=foo
--password=`cat $HOME/pw.txt`
http://www.site.com/

but it is still there for you and root to see. Isn't there a way to hash or shadow the password in the pw.txt file so it's garbled to the plain eye? Or would the fact that the hash has to be translated out somewhere negate the benefits of just having good permissions on that file?

choogendyk · 11-17-2009, 07:04 AM

Well that makes it pretty clear why you don't want the password text in your crontab file. And the example for avoiding that shows exactly what I was saying about using `cat filename` in place of the text of the password. They also say, "(Note that some applications permits to read credentials from a file)", which, of course, is also what I mentioned, along with, some don't.

So, if you take the password approach to logging in, the permissions on the file containing your password are the critical link. If you hash it, you have to unhash it to submit it. That has to be coded. That code has to be protected with permissions, and you're sort of back where you started.

That's where certs come in. That's what they are designed for. That's what they do.

Of course, if you have a specific legacy application that requires a password login and that has no way of using certs, then you'll have to use the password in a file workaround. Make sure you have a trusted user account to do it, and make sure only that user account can access the file.

DJOtaku · 11-17-2009, 07:08 AM

Thanks for all the help. That really has given me a lot to mull over.