How to hide "system" function execution in a C program from ps?

read the password from a file and restrict the permissions on that file.
or
read pass word interactively from user
or
include password in the code - a hardcoding

All methods have some weakness
first and last store password in clear text so there are chances of password being compromised. Second one cannot run without user interaction.

Yet another option is to keep the password encrypted in a file.

>> please provide me a solution how to hide the password when executing a statement using "system" function.
>>>I don't believe there is anyway you can prevent the. The solution is not to use the system function but to do this in code.

>>>What is it you are trying to achieve here? Lets see if we can find a C way of doing it.

In the 'C' program, I am executing a bash inline statement, where I have to supply a public key (password) to the gpg command to decrypt the encrypted file, add2numbers.sh.asc.

system ("echo password | gpg --no-tty -q --passphrase-fd 0 -d add2numbers.sh.asc | bash -s 3 4");

But while executing the corresponding 'C' code, if anyone tries to crack the key, he can do it easily by doing a "ps -ax", where he can see the same statement as one process.
He can easily see the public key, "password".

I am trying to give protection to all the shell scripts and some flat configuration files by encrypting them and trying to run them after decrypting and executing from a 'C' program through "system" function. But system function reveals everything when you check the process status through "ps -ax" command.

>>read the password from a file and restrict the permissions on that file.
>>or
>>read pass word interactively from user
>>or
>>include password in the code - a hardcoding

You are right. But this is not the best solution. Changing the permission will not help as the intruder can have admin priviledges.

>>All methods have some weakness
>>first and last store password in clear text so there are chances of password being >>compromised. Second one cannot run without user interaction.

>>Yet another option is to keep the password encrypted in a file.

Again the same problem to decrypt this file. How to hide this second password again?

If you still want to use system, then you could do something like :

system ("gpg --no-tty -q --passphrase-fd 0 -d add2numbers.sh.asc < pwd.txt | bash -s 3 4");

where pwd.txt is a text file that contains the password.
If that text file is only readable by the user that runs your application, then seeing the ps entry won't help a cracker much, since he doesn't have access to the pwd.txt file.

I'd still recommend to take note of evilrix's suggestion not to use system though. Consider using a combination of fork and exec instead :

       http://www.yolinux.com/TUTORIALS/ForkExecProcesses.html

key to the file can be coded into your program.

If intruder has admin priv then password has already been compromised and system is anyway doomed. There is little any password hiding trick can do to save your system.

>> >>read the password from a file and restrict the permissions on that file.

Oops, it seems sunnycoder already suggested that. Sorry.


>> Changing the permission will not help as the intruder can have admin priviledges.

If the intruder has admin privileges with full access to the system, there isn't really anything you can do to automate this. The password will have to be stored somewhere somehow.

>>Infinity08:
>>If you still want to use system, then you could do something like :

>>system ("gpg --no-tty -q --passphrase-fd 0 -d add2numbers.sh.asc < pwd.txt | bash -s 3 4");

>>where pwd.txt is a text file that contains the password.
>>If that text file is only readable by the user that runs your application, then seeing the ps entry won't help a cracker much, since he doesn't have access to the pwd.txt file.

I repeat the intruder can be a system administrator.

>>I'd still recommend to take note of evilrix's suggestion not to use system though. >>Consider using a combination of fork and exec instead :

I am not at all particular of using "system" or "fork" and "exec". The basic problem is that I need to execute a command where I am passing a key. I am not able to hide that key.

Use of "fork"+"exec" or "system" to execute any command displays that command through "ps -ax".

>> I repeat the intruder can be a system administrator.
Once physical access to the box has been achieved there is little you can do to protect. Especially if the intruder has admin rights.

>>key to the file can be coded into your program.
HOW?

>>If intruder has admin priv then password has already been compromised and system is anyway doomed. There is little any password hiding trick can do to save your system.

Cracking the public key stored by GNUpg is not very easy. The public key is generated by an intelligent program which is regenrated by the 'C' program I am talking about. This key is matched with the public key stored in the target machine to allow any encrypted script to get executed. If the intruder has admin priviledge, that does not mean he can do anything he wants. Am I right!!!

you need password to be somewhere on the system or accessible to the system. Admin can access entire system and everything that is accessible to your system. So nothing we do will help you in this case.

>> I am not able to hide that key.

As said : if your assumption is that the intruder will have superuser privileges, then you've already lost :) You're fighting a battle you can't win heh.


>> Use of "fork"+"exec" or "system" to execute any command displays that command through "ps -ax".

That's not your most important problem. If your intruder has superuser privileges, he can pretty much do whatever he wants, and he will probably not have to look at the ps output (that would require him to look at it at the exact right moment) to get the password, since he can simply retrieve it from the hard disk - wherever it's stored.

>> that does not mean he can do anything he wants. Am I right!!!
There isn't much he can't do... I think if you've an admin rights intruder your problems go a lot beyond this one :)

>This key is matched with the public key stored in the target machine toallow any encrypted script to get executed. If the intruder has
>adminpriviledge, that does not mean he can do anything he wants.
public key cryptography means that you need a secret private key for decryption and this key will be on the system or accessible to the system - again within the reach of intruder. You can use as strong an algorithm with as long a key as you want, but there is no way you can prevent the key from being compromised

>> I repeat the intruder can be a system administrator.
>>>Once physical access to the box has been achieved there is little you can do to protect. Especially if the intruder has admin rights.

Protecting in what way? By storing a file which stores the key.
Or he can do whatever he wants? I don't think so.

I have mechanism in place to protect the code. But I cannot store a file physically on disk which will be holding the key/password. The password/key handshaking should happen in memory.

>> I have mechanism in place to protect the code.

If the intruder has superuser priviliges, then he has access to the code ;) I'm not sure how you intend to protect against that.


>> The password/key handshaking should happen in memory.

Yes, but where does your application get the password from ? It has to be stored somewhere ...

It is an effort to make the decryption of files diffcult and give a feeling to the intruders that the code is protected in some way. Nothing is impossible in this earth. Anything can be cracked. But here it is not the situation where you will find intruders sitting all around. Here the intruders are lazy enough to dig into the problem of cracking some algorithm :) so no need to worry for that.

Just to make the things difficult to unhide the encrypted code, we always follow some protocol and we will also be following the same.

Instead of going beyond the context and fighting for the system security issue, let's focus on the actual point. What would be the best way to follow so that password/key handshaking should not happen on disk and the key should not get revealed easily for the problem I am talking about?

>> What would be the best way to follow so that password/key handshaking should not happen on disk and the key should not get revealed easily for the problem

I've already answer that, write it as native C solution. As long as you execute system() you'll leave a foot-print in ps, there is no way (simply) to avoid this. The only other way is to store the data in a file but you have ruled this out.

BTW: Even doing it in native C code isn't secure in so far a it is possible to reverse engineer a compiled program.

Basically as long as someone has admin access to the box there is little you can do to protect this. This isn't off topic, it is a fundemental point to the question you are asking. Once physical access is attained all security bets are off.

>> Here the intruders are lazy enough to dig into the problem of cracking some algorithm :)

An intruder who is dedicated enough to obtain superuser access to a machine, but would be stopped by an algorithm ? That doesn't sound very plausible.


>> Instead of going beyond the context and fighting for the system security issue

I thought that was exactly the issue : system security has been compromised because an intruder obtained superuser privileges. So, you're basically trying to keep data safe on a compromised system. It's like putting your money in a bank that you know has the doors and the safe wide open, and expecting that your money will be safe.

>>I've already answer that, write it as native C solution. As long as you execute system() you'll leave a foot-print in ps, there is no way (simply) to avoid this.
Forget about system(). Now, I think I have to remove the system() function from the glibc. haha. It was a function to explain my problem to you. Not all particualr about this function call.

>>The only other way is to store the data in a file but you have ruled this out.
yes.

>>BTW: Even doing it in native C code isn't secure in so far a it is possible to reverse engineer a compiled program.
Aha...gr8. please tell me how can I do it in native C code. Forget about reverse engineering of 'C' code. It is not possible for the type of intruders I am talking about.

>>Basically as long as someone has admin access to the box there is little you can do to protect this.
We know the type of intruders. Plzzzzz do not worry for this.

>>This isn't off topic, it is a fundemental point to the question you are asking. Once physical access is attained all security bets are off.
The whole story is not explained to you. Because of patent issue. I bet it is hard to crack my system evenif somebody is getting the full physical access to all the encrypted files.

I am neither particular about C nor any particualr language.

>> It is not possible for the type of intruders I am talking about.

That doesn't make sense. An intruder that has the skills to gain superuser privileges surely has the knowledge to get a password out of an executable. If you're not careful, a simple

        strings executable

will already reveal it.


>> We know the type of intruders. Plzzzzz do not worry for this.

Care to elaborate, because I don't understand.

>>>>An intruder who is dedicated enough to obtain superuser access to a machine, but would be stopped by an algorithm ? That doesn't sound very plausible.

I am repeating reverse engineering of my system is not that easy. I am betting on this.

>>>I thought that was exactly the issue : system security has been compromised because an intruder obtained superuser privileges. So, you're basically trying to keep data safe on a compromised system. It's like putting your money in a bank that you know has the doors and the safe wide open, and expecting that your money will be safe.

There is difference between my doors being open and illusion of being opened. So it is not only the gpg tool which protects my system, but also many other security features. I have security guards, tankers, big battalion in the bank to protect my money. HAHA. Don;t worry for that.

>> I am repeating reverse engineering of my system is not that easy. I am betting on this.
Security by naivety is not security.

>> I have security guards, tankers, big battalion in the bank to protect my money
Would they see a mouse slip in?

>> So it is not only the gpg tool which protects my system, but also manyother security features. I have security guards, tankers, big battalionin the bank to protect my money. HAHA. Don;t worry for that.

Euhm, if the doors are open, I'll simply throw in a bomb (with sleeping gas ;) ), watch the battalion get blown up, then simply stroll in and walk out with the money.
Or for your system : you do realize that a superuser can disable whatever security measures you put in, don't you ?


We are trying to give you good advice here, but if you still stand by this :

>> I am repeating reverse engineering of my system is not that easy. I am betting on this.

then what's the problem really ? You obviously have thought of everything, and since the intruders won't pose a problem (except for looking at the ps output), you can simply use any of the techniques already suggested.

I don't want to bet on it being secure like you would though.

>> Not a great solution!!! Please do not divert yourself from the question when you do not have the proper solution.
I can't give you a solution if there isn't one to give. The answer I have given you is correct, it is not wrong in any way.

We were not diverting from the problem, we were trying to ensure you were aware of the scope of it. The question and some of your comments suggest you really are not and it would be irrisponsible for us to give you a half-baked solution without making sure you are aware of the implecations of what you are trying to do!

If you still feel like we have not assited you then I suggest you reopen the question and wait for additional answer.

>> I suggest you reopen the question and wait for additional answer.
In fact I'm going to do this since (a) I am not happy with the comment you have posted in your close comemnt and (b) I don't think this Q actually adds anything useful for the PAQ database!

http:Q_23549882.html

I8, I hope you don't object.

>>> Not a great solution!!! Please do not divert yourself from the question when you do not have the proper solution.
>>I can't give you a solution if there isn't one to give. The answer I have given you is correct, it is not wrong in any way.

>>We were not diverting from the problem, we were trying to ensure you were aware of the scope of it. The question and some of your comments suggest you really are not and it would be irrisponsible for us to give you a half-baked solution without making sure you are aware of the implecations of what you are trying to do!

>>If you still feel like we have not assited you then I suggest you reopen the question and wait for additional answer.

evilrix!!! Please do not feel bad for the comments. When I am talking about gpg, please do not think the security problem is over there. Same here as well. My research is on that. I have lot many other features which secure my system. I have remote system key-exchange mechanism in place. I have developed file-tampering tool with encryption/decryption mechanism. Developed my own advanced cryptic script-obfuscator, root-user abator and few others. I am not going to explain how my system is secured over here. It is a place where experts reside and I appreciate your efforts. But come to the point and answer to the question. Please do not dig into the issue which user does not want to reveal. If there is no solution, then say "No, not possible". That would have answered my question.

Anyway Thanks for the efforts.

>> But come to the point and answer to the question
>> If there is no solution, then say "No, not possible". That would have answered my question.

I did that in my very first post (the very first post to this thread) http:#21961461
"don't believe there is anyway you can prevent the. The solution is not to use the system function but to do this in code"
Which part of that wasn't clear enough for you?

We then endevoured to try and find an alterative but lack of infomation from you made this unfeasable.

>> I am not going to explain how my system is secured over here.

If an intruder gaining superuser access is considered "normal", then I wouldn't say the system is secure ;)

>> How should we dispose of this question? Rx suggested a simple delete, but I'll entertain recommendations.
I'd just leave it open until either clean-up or the OP decides to close it himself properly. I don't object to the C grade, if that's what the OP feels it's worth then so be it but I do object to the implication that we were not being helpful. Questions regarding security issues cannot just be answered with glib responses since they could lead the Asker down a path that leaves them at risk. All the experts in this thread were trying to ensure the OP understood the implications of what he was doing. It is clear from some of the reeponses that this may not be the case. Maybe we are just too caring :)

I feel that evilrix and infinity08 were right in trying to make the asker realize that the approach he is proposing to take is fraught with peril. However, apparently asker seems to be sure that this is the way he wants to take.

It is unlikely that a discussion would now ensue in this thread. I would suggest opening another thread with all the constraints laid out in the question itself. That way there is a better chance of having a discussion that is useful to the asker.

This question can probably be awarded without adding to PAQ database - Is that possible?

No objection, but just to point out this Q was answered correctly. {http:#21961461}
My objection was to the unnecessary comment made against the closure.

My 2c worth,

The initial opinion of the experts was, essentially, 'there's no point trying because if an intruder can see the command line they can see everything else anyway'.

When asker attempted to guide his question towards 'forget whether its worth it, can it be done' experts seemed unable to divert themselves.

If someone had suggested something like 'download gpg source and make a library out of it' then perhaps asker would have realised that although there are solutions they are essentially unfeasible.

To my mind, a C grade is a little harsh. The advice being given was essentially the best advice.

To my mind, asker was correct in pointing out that experts had not allowed themselves to be diverted but the wording of the note seems a little OTT to a native English speaker.

I hope I haven't ruffled any feathers. :)

Paul

>> I hope I haven't ruffled any feathers
Hi Paul, Nope. :)

The essence here is that we were trying to ensure the OP understood the implications of what he was trying to do. This was not apparent (to me at least) from the responses we were getting. I did point out that given the original requirements it couldn't be done. This was embodied in my first post.

Um, why are my comments suddenly in Orange?

You are right, Paul. But I don't want to be responsible for giving a false sense of security, by omitting important advice. When it comes to security, nothing is unimportant, so the statement that we shouldn't worry about the fact that intruders gaining superuser privileges is considered normal and harmless, brings out large red flags, flashing lights and alarms everywhere for me. I cannot ignore that heh.

But yes, I agree with your analysis ;) I will not allow myself to be diverted on this lol.

Dear PaulCaswell, evilrix and Infinity08,
I am very sorry to see you all fighting for the grade given to the solution. The grade is given from my side considering all factors. The type of solution given is very straight forward without giving much details about it.
If you see all the conversations one after another, it seems like you all are focussing on the same issue which is not that serious for me. I appreciate Mr. Evilric and Mr. Infinity08 to bring out the the issue of how insecure my system is. But I wanted you all to tackle the problem little differently. As Mr. PaulCaswell came up with a possible solution "why not library of GPG?", that could have been helpful to me. Seriously speaking I tried that, but it is going to take little bit more time for me to dig into its API's and use them. But I found the solution in gpg itself (Running gpg-agent as a service will solve the purpose by placing the password/passphrase/key in memory for few use-defined seconds. gpg-client can read the passphrase withe help of gpg-agent by reading the same from memory location). Please read the following excerpts from the link,
http://ohioloco.ubuntuforums.org/showthread.php?t=819719 where the GPG-developers talk about the security of GnuPG.
---------------------------------------------------------------------------------------------------------------------------
"How secure is GnuPG? Who really knows? Only the NSA knows for sure -- and you think they would tell us? By best accounts from the world's leading mathematicians however, the algorithms used with GnuPG today would take the best computer, many years to break (if at all). Again however, the downside of gnupg, is the loss of the password, or private keys. Its much easier for a rogue per se to do something to obtain the keys through subversive another process, than break the underlying algorithm."
---------------------------------------------------------------------------------------------------------------------------
Apart from this GnuPG tool , we have many other secured mechanisms in place. So, for the time-being this much of security is enough for our initial version of our software, which does not worth it. Later on we will come up with better secured mechanism for our next version.

If suppose I will ask a fresher in Linux domain, I will ask the same question then he would have come up with the similar comments what Mr. Evilixr and Mr. Infinity08 had given. Super-user permission!!!! ==> "No security at all". This much of sense I too have my dear friends. So, when I am repeating many a time not to worry about for that, you people did not listen at all. I felt I am in a discussion forum which is not going to help me more than what they have already discussed. So, I purposefully closed the question with some grade. But as Mr. PaulCaswell mentioned, I became little harse in the grade side. For this I am very sorry to the group. My kind request to you all to help others and attack the right point what the asker is battling for.
There are one more solution for the problem I had asked for. Please read the following link.
http://www.uaex.edu/srea/Hiding_Passwords_From_Unix_ps_Command.htm
But this is not a perfect solution. If you do "ps -ax", it may not show the command, but if you grep the particular process from "ps -ax", it will show you the whole command totally. And the root user can read the "proc" files by some means easily to get the password.

I found the solution along with your support :)  THANK YOU ALL FOR ALL YOUR SUPPORT. Please delete the question!!!

sunneycoder,
I apologise for being rude and for my statements being insulting. I am very sorry to the community.

Expecting Gurus, Sages to provide me correct path (which they are providing) "quickly" if they can without repeated suggestions as I cannot buy time. And here I have been helped out lot of times. Thank you all for that.

All these things happened as I could not give them a clear picture (which I cannot for lot of reasons, please understand) what are the security measures I am taking for my system. Please do not offend the asker when he/she is confident about something. I am ready to take your suggestions as really those are valuable. But my kind request not to dig into the problem which I do not want to reveal.

(FYI: There are lot of third party softwares available in windows and linux, which do not require the passwords or keys to be available remotely all the time. And it is not an "easy" task all the time to crack a system, evenif you have super-user privileges. It is matter how to make the intruders' task harder to crack the system-security, not to make it impossible.)

Sorry once again.
-Regards

>> I am ready to take your suggestions as really those are valuable
I have answered this Q in my first post, all other suggestions made were additional to this and were an attempt to try and assist you further, beyond the scope of the original question. I have nothing further to add.

Please also note that I find myself unable to assist those who are rude and offensive to those who are only trying to help them. A belated apology once you've calmed down does not, in my book, excuse your original behavior (especially as you had no reason to be 'un-calm' in the first place) and I am no longer willing to assist you in this or any other thread anymore than I have already done.

Note to ZAPE: I would request you DO NOT remove this comment.

BTW: Why are my posts all orange? Also, why are the OPs. What is going on here?