What do you thing it will be the optimal method of passing passwords to different applications.
Giving the password as a command line argument is not acceptable because this will be visible in logs - especially in an automation system.
At this moment I'm considering two possibilities: providing the password in a file or temporary setting it in an environment variable.
Please give your recommendation and explain it.
Related
Is it possible to execute a method as a different user in Linux (or SELinux specifically)? The programs that I have run in individual sandboxes, each with a different user and process id. I have a situation where I have to execute a branch of code as a different user and with different process id to prevent the access of the memory and disk space of the code that's spawning it.
If not possible, can you throw some light on how much of the kernel code has to be changed to achieve it? (I understand its subjective. Alternatively, if you can suggest what and how to go about it, that will be much helpful).
Protecting some resources from other codes executing on the same machine is precisely what lead to the process and UID invention.
If you are searching for a mechanism that looks like a simple function call, I would say it's impossible because it requires the memory to be shared between the caller and the callee. However, using fork/exec (or wrappers like system()) will give you some isolation as long as you deal with parameters/results using system objects like program parameters or pipes.
Although, the fact that *nix user is meant to protect processes from one-another, requires that an explicit relationship be built between two users to have one user act on behalf of the other.
Actually, you may want to:
define a sudoers policy which gives the right to your first user to run a command (or a particular command) as the second one.
use popen() (or system()) in your first program to call the less privileged code.
if any, pass the parameters and parse the result from stdout
As an extra, you may use the same binary for both executions, this way, all the code can be at the same location.
Just found that SQLPLUS would parse the first line of a sql script as connect string if I do not include the credentials when invoke sqlplus in the terminal, details are listed below:
I have a sql script named runme.sql:
scott/tiger#//localhost:1522/orcl
select * from dual;
exit;
If I invoke sqlplus as sqlplus #runme.sql , sqlplus could parse the first line and connect to database and run the sql. Can anyone point me to the documentation for this if there is any ? Also what are the advantages for supporting this syntax ?
The documentation is usually a good place to start. Note the warning if you supply the username/password on the command line; providing at least the password when prompted is more secure, and particularly in Unix-type environments means the credentials don't appear in the output of a ps command.
Putting either the password or both the username and password in a script automates that, but of course you have to then ensure that the script can't be viewed by anyone who shouldn't know the credentials.
As LalitKumarB notes in a comment, hardcoding the password anywhere is a security risk. If you're running scripts interactively then allow the slight inconveince of being prompted each time. (Which isn't really inconvenient when compared to the damage that could be done from the credentials being misused, and subsequent inconvenience of recovering, and/or finding a new job). If the script isn't being run interactively then use the scheduler rather than, say, cron. You can also use Oracle Wallets for greater security without so much inconvenience.
Specifically for your query about it parsing the first line, the documentation says:
If you do not specify logon but do specify start, SQL*Plus assumes that the first line of the script contains a valid logon.
In this context 'start' is the same as using # on the command line to supply the script name.
I have a project running in vb.net. It's currently a very small project, so I have used XML serialization as the main way of storing information. I.e. creating a xml file in the .exe folder. and saving/reading from there.
Problem: Since the project is small, I have no SQL database setup and I would like to keep it that way. But I do want to create a user/password for access to the program.
What I have tried: I have tried using XML serialization, but hiding the xml file. Once I hide it, I'm unable to access the file (saying I have no permissions).
What's a good way to have the same utility without using SQL and not giving away security?
Hiding the file is pointless. You should simply hash the passwords and then store the data just as you do for any other data. That's exactly what you'd do if you were using a database too. When a user registers, you hash the password they provide and store the result. Anyone can then view the data without breaching security because they cannot get the original value from the hash. When a user logs in, you hash the password they provide and compare that to the value in the database and, if they match, the user is authenticated.
You should do some reading on hashing in general and also consider adding a salt for extra security, although that may not be worthwhile in this case.
I have written a kernel module that creates a /proc file and reads values written into it from a user program,say user.c
Now I want restrict permissions for this /proc file.I have restricted permissions based on userid using the 'current' kernel variable by checking current->euid.
My question: Is there a way to restrict this based on the program too? i.e. only user.c should be able to write to this proc file and not any other program.I could not find any parameters in task_struct that would help me do this. Can you please suggest a way to do this?
In your proc writer implementation (that is, inside the kernel module) the best you can do is check the value of current (a struct task *), which holds (among other things) valuable fields such as comm (16-character argv[0]), pid, uid, etc (Basically, everything you see in /proc//status. You can also check the original exe name (like you see in /proc//exe), to see if it's a well known path. You can then return an error.
Caveat: Anyone could rename their opening process to be one of your "allowed" programs, if you go by "comm", and there are ways to defeat the "exe" protection. This will only make it slightly harder, but not impossible for someone to get around. A more comprehensive and stronger solution would require you to peek at the user mode memory of the program, which is possible, but too complicated for a brief answer.
Note: Permission parameters won't work, don't even bother. They go by classic UNIX ACL, which is u/g/o - so you can't filter by PID.
Is there any way to automate the user input in a ksh script?
I realize that in many instances you can create an expect script to do exactly what I am saying, but expect is not installed on the server and there is no chance of that occurring in the near future. But I still need a method of automating user input so the only reaction required is to start the script.
If you have the complete set of "user" input, you can redirect stdin:
script.ksh <userinputfile
If you have some of it, or generate it on the fly, you can use "hereis" documents.
If you are going to be parsing prompts, the easiest way, as you mention, the easiest way is to use Expect. Even if Expect isn't available on the server, it'll be easier for you to include as much Tcl/Expect as necessary to do your parsing than to rewrite and redebug it.