[SOLVED] Advice on best / safest way to capture root password

grail · 05-31-2011, 09:18 AM

So hopefully this didn't throw up too many alarms. This is not about hacking anyone.
Now that that's out of the way.

Background:

I have a script which when invoked will generally su into being a number of different users (for those that have read other threads from me, you will know
I am building my own user based package management system). Whilst 75 - 80% of the time there will be no need to be anyone other than the original user, there are
times when the root password is required.

Currently this is presented to the administrator at exactly the point in the script that it is required. At times this may be more than once and it may also happen
for multiple users in a row.

Question:

What would be the best / safest method (in your opinion) of capturing the password at the start of the script and then delivering it when required?

I have looked at expect ( I am not at all familiar ), but on the examples dealing with passwords, that I could find, they all seem to store
the password in a simple bash like variable (which does not excite me at all from a security point).

I can also potentially go down the sudo road, but the issue here is that I would either have to find a list of commands that an entire
group can have access to without passwords (doesn't sound safe) or I am back to square one of then requiring a password for each individual
user to be entered, which if at the start would still need to be captured and saved until necessary.

So as I have said, I am open to any and all (constructive) advice

PS. Currently all scripts for the packaging system are written in bash with the occasional awk snippet flying around.

cheers
grail

Guttorm · 05-31-2011, 09:48 AM

Will the users have sudo root access with their own password? Then you don't need to store the password at all, because of the sudo timeout. What I mean is that this script only ask for my password once.

Code:

#!/bin/bash
sudo ls /root
sudo ls /root
#This one fails, but I can switch user any time:
sudo -u guttorm ls /root

grail · 05-31-2011, 10:05 AM

Currently sudo is not installed, but as I said it can be if it proves to be a solution.

My issue around the timing (although I am guessing it can be set as to how long you want it) is that the scripts are used on a source distro hence the tasks are around
compilation which as you know for something like gcc is a long time but for say less it is relatively quick.
Also, some will require it as a part of the preparation to install, an example is bind where it requires the addition of a user and the way my scripts work
it needs to be done prior to compilation, where others, like grub who have to run grub-mkconfig which requires root access, are run at the end.

Also, correct me if I am wrong, but if I was to do a system rebuild, your solution would require me to type in passwords for all (currently) 85 users (applications)?
And this is a base system so when it grow to include X this number would be extremely large

Guttorm · 05-31-2011, 10:48 AM

Hmm.

The default timeout is 15 minutes. You can set timestamp_timeout in /etc/sudoers. Or you could just "sudo -v" every 14 minutes or so, to update the timestamp. I think this could be run in the background. And it doesn't need the password to run commands as different users. For example this script asks for password once:

Code:

#!/bin/bash
#the first sudo will ask for the user's password:
for user in $(cut -d':' -f 1 /etc/passwd) ; do
echo $user
sudo -u $user touch /tmp/touch.by.$user
done
#kill the timeout, we don't need more root access:
sudo -k

AnanthaP · 05-31-2011, 11:01 AM

Safest is to go down the hashing/message_digest route. Though it involves writing a bit of code (Java for portability) that isn't

Quote:

Currently all scripts for the packaging system are written in bash with the occasional awk snippet flying around.

Also if you want to enhance your script later to a browser based solution - say, then the Java code could be substituted by an applet.

The process I believe would be known to you. In this case, store the hash and only the hash at the point of data entry.

OK

crts · 05-31-2011, 12:24 PM

One major problem with variables storing passwords is that they might be swapped out. Especially, if you do RAM intensive tasks like compiling and testing programs like gcc, glibc etc. I googled a bit but could not find a useable solution to this. I found this thread
http://ubuntuforums.org/showthread.php?t=775972

This is basically the same idea - if I understood correctly - as AnanthaP suggested. Write a small program that will prevent its variables being swapped out. Use this program to feed the value of the variables to the corresponding program like passwd, su etc.

I would also discourage the use of sudo. I am not 100% sure but your users would no longer be passwordless users. Or even worse, if you put them in the sudoers file they ??might?? be able to gain root rights without even providing a password. But I think/hope that the latter is not possible. Haven't tested it yet.

Nominal Animal · 05-31-2011, 05:03 PM

Quote:

Originally Posted by grail

I have a script which when invoked will generally su into being a number of different users (for those that have read other threads from me, you will know I am building my own user based package management system). Whilst 75 - 80% of the time there will be no need to be anyone other than the original user, there are times when the root password is required.

When I automated my LFS build scripts a few years back, I had a similar situation, except with fewer user accounts: I only used my own, a dedicated build account, and root.

The simple solution was to add a preamble to the script, which saves the original user name in an environment variable, and uses su or sudo to switch to root for the rest of the script. Parts that do not need root rights, are then run as the original user (or some other user) via su.

It does complicate the script a bit, and you may want to split the script in two parts -- first part is run by the user, saves the username, then execs the main part (located out of PATH in a root-access-only directory) via su or sudo. The main part then checks it is run as root, and that the username is in an environment variable (and does not map to root).

The upside is you can maintain the package data as a dedicated user if you wish (like I used a dedicated build user account), so you don't need to do stuff as root as often. It may be useful if your package management uses temporary directories, or even compiles source packages.

crts · 06-01-2011, 05:12 AM

How about not switching to root at all when using user-based package-management? Back when I automated my LFS ( with package-users ) I used several scripts. The first script was executed by root. It did store some information about the status of the installation and called the actual build-script for the package-user. If this user would need root access it would simply exit. The commands that need root privileges would then be executed from the root script. Then it would 'su' to the package-user again and execute the rest of the commands. In my case the rest of the commands were stored in a separate user-script but I guess it could also be done passing a parameter to the same script which will then determine where to resume.
Here is an excerpt:

Code:

	install_package -i $install/gcc "" gcc gcc $source/gcc-4.1.2


	rm -v /usr/lib/libgcc_s.so{,.1}
	rm -v /usr/lib/libstdc++.so{,.6}
	mv $install/gcc2 $homebase/gcc/build2
	chown gcc:gcc $homebase/gcc/build2
	chmod 700 $homebase/gcc/build2

	su -c "cd $homebase/gcc/gcc-build ; ../build2" gcc


	/sbin/ldconfig # always a good idea when using package-users

'install_package' is another script that does some configuration (user creation, copy conf files etc.) and then switches to the package-user. It calls the package-user's build script which has a default name. The items in red are run by root when the user exits. The last part of the build-commands are then run by calling
su - ...

and switching to the user.

So there was really no need for a root password to be asked or stored. Of course, implementing this as a general-install mechanism will be a bit more complicated. But you probably know that already

Using package-users and a general install-admin with more privileges than a normal package-user but still less than root might have benefits regarding security. This would complicate the calling mechanism without having to ask for a password. But I *think* it can be done.

Before I go into further details please let me know if you are considering this approach (*simply* exiting) at all or if it raises too many conflicts with the concept that you have implemented so far.

grail · 06-01-2011, 06:15 AM

Thanks all ... I am digesting all the answers.

Currently I agree that sudo is not the right option for the system as the user (package names) have no password so only root can perform any changes.

The main script (which can only be executed by root) after checking that the things to be installed exist and the dependencies have been met,
it already calls a second script as the individual user to perform all of the compilation tasks required to install the package. As I attempted
to outline originally, it is at this point, ie during the processing of the compilation tasks, that the root password may now be required. Due to
the order of some of the tasks it is not possible to perform them prior (ie whilst still root) and then finish the installation.

I will investigate the additional script / program option that crts and AnanthaP outlined.

Having had a quick read on the idea I was wondering what some of you might think of the idea of having an encrypted file save the password which can then
be accessed for it information when needed? Although thinking further I guess the issue then becomes how to access the encrypted file without again storing information

If anyone has anymore idea, please feel free to add. I will leave this query open a while longer and try to advise on what sort of decision I come up with

grail · 06-01-2011, 06:42 AM

hey crts ... was typing mine while you were (just took me ages while watching telli

)

I do follow the jump out idea, but not sure right this second on whether it would require a very large rewrite of current code.

Here is a broad scope of current scenario:

1. All compilation options are stored in several files with what is required

2. root calls a script like your install_package which processes command line information and dependency checking and so forth. This then calls a second script using su - user -c script

3. Whilst the second script it is running it references the files from step 1 (if anyone has heard of Sorcerer / Sourcemage this is similar process just not user based)

4. On finishing the script passes back to the initial script run by root and then the next package is processed

So I am just not a 100% sure, if using this process outline, how when dropping back to root I can say process yet another file and then jump back to script and correct point within external
files to continue. Also, files from step 1 are sourced when the second script is executed, so all the data would then be lost once dropping out to become root again.

I have attached 2 of the package user folders to give you an idea. The STORY file is the one to look at, but all others are referenced. (You will need to remove .txt prior to extraction)

crts · 06-03-2011, 02:43 AM

So I had some time to look at the scripts. But I do not see how exactly STORY is processed? If I understood correctly, then STORY is sourced as package-user by the second script, right? Could you attach such a second script?

gnashley · 06-03-2011, 06:18 AM

Are you sourcing the second script, or executing it? Sourcing would run it in the same process so you wouldn't lose changes to the environment when 'leaving' the sub-script.

grail · 06-03-2011, 06:38 AM

Hey crts

Always happy to share

Please don't look to hard though for good documentation as I have that mainly in separate notes

I do however think that it should be fairly easy to follow.

I have included 4 files:

1. dictionary - this contains all variables that are sourced at the start of the editorials file

2. editorials - sourced commands that are used many times within other scripts (I have 2 other scripts that are not used in this process)

3. imbue - this is the default script that root must call to get the ball rolling (currently this version does not include dependency checking which is done by hand)

4. scribe - this is the script invoked as the package user which will incorporate the BIO and STORY files attached previously

If you have any questions at all please feel free to ask away

Also, if you can see any serious issues (not that I want you to spend too long if you do not wish too) please feel free to point them out and / or advise on what you feel might
be better

cheers
grail

crts · 06-11-2011, 01:20 PM

Hi grail,

it's been a busy week but I finally had some time to think about the problem. The fact that you source the build-scripts does complicate things a bit. So I dropped the idea of exiting and reentering.
However, it should be possible to suspend execution of the scripts via
kill -SIGSTOP $pid

and give back control to the parent script by trapping the signal 'SIGCHLD'. The parent script can then take appropriate actions. The sourced file will copy a set of instructions - that are to be executed by root - to a specified location, e.g. /etc/callback/rootexec. Then 'kill -SIGSTOP' (you might wanna throw in a 'sync' and/or 'sleep 1' first) is executed and control is passed to the parent. Since you 'su' from the root-script to the user-script which then sources some sommands and executes them in a subshell there are three processes that need to be paused:

Code:

1. the subshell that runs the sourced functions. This is done from within the function that needs
   to execute some commands with root privileges.

2. the parent-user-script notices - by trapping 'SIGCHLD' - that the subshell is paused. It then
   needs to suspend its parent-process (that is 'su') first and then suspend itself.

3. now finally the root-script (also traps 'SIGCHLD') gets notified about the suspension of the
   user-script and looks for the file /etc/callback/rootexec and executes the instructions

I have attached a set of scripts to demonstrate the mechanism. Before you can use them you will have to create a user by the name 'dummy' first. Then you will have to as root:

Code:

mv user.script user.sourced /home/dummy/
chown dummy:dummy /home/dummy/user.s{ourced,ued}
chmod 0700 /home/dummy/user.sued

Now call './script-root' as root. The script should display some info on who is executing what and do a 'ps' regularly. The 'ps' commands are the instructions that have been passed from the subshell that executes the sourced functions to be run by root. The different colors indicate by whom the current command is executed.
You will notice that there are a couple of 'sleep' and 'sync' commands. Not sure if all of them are necessary but at least some of them are needed. You can have a play and remove some of them and see what happens. In this case, however, you cannot rely upon that the colors will inidcate correctly who is executing what.

I created the scripts to simulate a simplified calling mechanism as in your original script. Hope, I got it right.

Keep in mind, that those scripts are just a crude outline for demonstration purposes only. If you decide to implement that mechanism than you will have to take some additional measures into consideration, e.g.

check if the file /etc/callback/rootexec has been created by a legit package user

find a better way to identify the caller. I just hardcoded the names and used three files where the caller put its pid in. Is there a better way? Probably!

Errorhandling! Currently there is none. Things will get very strange if an error occurs right now

to name just a few. You will also notice that the script exits very ungraciously. This is because when a child-script exits the parent also traps this signal. Since there is no process 'kill -SIGCONT' returns an error. The pid and rootexec files are also not removed so the parent just executes the last rootexec script. It should be no problem to correct this behavior by removing the corresponding files and have the trap check for their existence before doing anything else.

I have not used traps very often until now. So you better read up on 'trap' and double-check my proposed mechanism.
Let me know if there are any 'booby-traps' that I failed to see

grail · 06-12-2011, 01:49 AM

Thank you so much for all of the feedback and I will definitely test the scripts when back my machine. I will let you know of what, if any, problems I run into

Hope following my code was not too difficult. If I may ask an opinion question, does it look like a reasonable enough undertaking (so far)?

Feel free to let me know if you saw any really huge issues