I'm running salt under unprivileged user. The idea is to make some states that can be executed under different unix users, but without giving root privileges to anybody who executes the state. So the question is if it is possible to somehow tell salt to ask for password when switching the user either via runas or when specifying user like in cmd.run. Effectively I would like to achieve something like:
salt '*' cmd.run runas=myuser ask_for_pass=true 'whoami'
test1:
> enter pass for myuser:
'myuser'
or in the same in a form of state:
whoami:
cmd.run:
- user = myuser
- ask_for_pass = true
or one more example that is closer to what i'm actually trying to achieve - installing jboss for a different user (salt-minions and master are running as user "salt"):
$ salt 'host1' state.jboss runas=jboss_user ask_for_pass=true
Salt doesn't do exactly what you're wanting to do here.
Your best bet would probably to use the client_acl or external_auth master config options.
These both will allow you to give either a system user or ldap user the rights to run specific commands.
client_acl docs for authorizing system users: https://docs.saltstack.com/en/latest/ref/clientacl.html
external_auth docs for authenticating external users from PAM or LDAP: https://docs.saltstack.com/en/latest/topics/eauth/index.html
So for example, if you had set up LDAP external_auth, you could require your users to do the following on the command line:
salt -a ldap '*' state.jboss
Salt would then prompt the for a user and password.
Related
I want to do a remote shutdown using a batch file and access is always denied (5) using just the shutdown command.
If I type:
Net Use \wtp-iba password /user:user
CMD always returns the user name or password that is incorrect.
However, if I type:
Net Use \wtp-iba
and hit enter CMD prompts me for the user name and then password the connection is successful and I can use the shutdown command.
I have tried many things I have read and none has worked.
Help, please!
Can someone please give me an example for corporatePasswordStore that is mentioned here:
https://docs.corda.net/node-administration.html?fbclid=IwAR0gRwe5BtcWO0NymZVyE7_yMfthu2xxnU832vZHdbuv17S-wPXgb7iVZSs#id2
I've been doing a lot of research in the last few days on how to hide the plain passwords from node.conf; it's a new topic for me and this is what I came up with so far:
Create a priv/pub key with gpg2
Create a password store with pass (using the key that I generated earlier).
Store all the plain passwords from node.conf inside that password store.
Replace the plain passwords in node.conf with environment variables (e.g. keyStorePassword = ${KEY_PASS})
Create a script file (e.g. start_node.sh) that will do the following:
a. Set an environment variable to one of the passwords from the password store: export key_store_password=$(pass node.conf/keyStorePassword)
b. Start the node: java -jar corda.jar
c. Restart the gpg agent to clear the cached passwords, otherwise you can get any password from the store without passing the passphrase: gpgconf --reload gpg-agent
Pros:
Using the bash file start_node.sh allows to set many passwords as environment variables at once (e.g. keyStore, trustStore, db passwords, RPC user password)
Since we are running the bash file with bash start_node.sh and not source start_node.sh, the environment variable is not exposed to the parent process (i.e. you cannot read that environment variable value inside the terminal where you ran bash start_node.sh
History commands are not enabled by default inside bash scripts.
Cons:
You no longer can have a service that automatically starts on VM startup, because the start_node.sh script will ask for the passphrase for your gpg key that was used to encrypt the passwords inside the password store (i.e. it's an interactive script).
Am I over-complicating this? Do you have an easier approach? Is it even necessary to hide the plain passwords?
I'm using Corda open source so I can't use the Configuration Obfuscator (which is for Enterprise only): https://docs.corda.r3.com/tools-config-obfuscator.html#configuration-obfuscator (edited)
I wrote a detailed article here: https://blog.b9lab.com/enabling-corda-security-with-nodes-configuration-file-412ce6a4371c, which covers the following topics:
Enable SSL for database connection.
Enable SSL for RPC connection.
Enable SSL for Corda webserver.
Enable SSL for Corda standalone shell.
Hide plain text passwords.
Set permissions for RPC users.
I'm deploying virtual guests this way:
salt-run virt.init vmtest 2 2048 salt://images/ubuntu-image.qcow2
It only partially works; vmtest is created and its key is added to the master, but the new minion never connects. So I pull up the vnc interface (which works fine) to see what's going on from the minion end, and...can't log in, because I don't know what credentials to use. Oops.
How do I specify initial login credentials when creating a VM with virt.init?
Well, this may not be exactly what you were looking for, but you can use libguestfs-tools in order to set a password on the image itself.
In salt, you can use cmd.run or pass it in a state to change the password after you install libguestfs-tools like so:
salt 'hypervisor' cmd.run "virt-sysprep --root-password password:'myrootpassword' -a /path/to/image.img"
or
update_pass:
cmd.run:
- name: virt-sysprep --root-password password:'myrootpassword' -a /path/to/image.img
Side note:
If you create or update the image you use to spawn new vms to pre-install salt, and update the /etc/salt/minion conf to set your master, and set it to come up at your desired run level, you should be able to work out a solution where the minion connects on creation.
Good luck, I hope this helps.
As per suid concept, if suid bit is set on any file/executable file and the normal user execute that command. command will be executed with the privilege of owner of that file/command.
suid bit is set on "passwd" command and root is the owner of passwd. Now if a normal user say "user1" execute the command 'passwd' it will be executed with root privilege. However, he can change only his password but not for others. why so?
/usr/bin/passwd program will check two conditions:
whether the current real user ID is equal to UID of the password item/entry;
whether the current user is root.
Only one of the two conditions is met, can the process modify the password.
Therefore, what prevents you from modifing the password of other users is the /usr/bin/passwd program, not the suid permission. Your understanding about suid permissions is correct.
See the link. Here is the answer from a Jjanel:
google: passwd.c
https://github.com/shadow-maint/shadow/blob/master/src/passwd.c
see lines 1056-1069:
Code:
/*
* If the UID of the user does not match the current real UID,
* check if I'm root.
*/
if (!amroot && (pw->pw_uid != getuid ())) {
(void) fprintf (stderr,
_("%s: You may not view or modify password information for %s.\n"),
Prog, name);
SYSLOG ((LOG_WARN,
"%s: can't view or modify password information for %s",
Prog, name));
closelog ();
exit (E_NOPERM);
}
By the way, forgive my poor English, I'm finding a good way to impove it.
suid bit doesn't make something run as root. It merely allows something to make the setuid system call, to elevate it's privileges.
passwd requires root privileges to update user credentials. It does this quite cautiously though - it starts in a user context, verifies stuff, and then escalates privileges to make the system change. It being set setuid doesn't have any bearing on this - it merely allows it to do this.
If you want to accomplish non-root password changing you should probably use sudo to run passwd as root.
IF you really want, you could write your own command that embeds a setuid system call, but sudo is probably the better approach.
I installed cloud-in-a-box/fastrack of Eucalyptus and am able to create instance and log into it. But when trying sudo, sudo su - or login in as root I'm asked for a password. I'm not sure what the password might be. Does anyone know what the default password for the Image is?
I think this is how the image is designed. It uses the cloud-user account only and has no root access, nor does it allow sudo.
There are other starter images available that can be "installed" that have sudo as root enabled. In those cases you simply issue
sudo su -
and you become root.
To see what is easily available use:
eustore-describe-images
As a note, some of the other starter images have different accounts (not cloud-user), such as ec2-user. If you don't know which account to use simply try to ssh into the instance as root and it will usually get a message back telling you:
Please login as the user "ec2-user" rather than the user "root".
I am not sure if there is a password on the root account in that image. Regardless, the recommended way to log into instances is by creating an SSH key (euca-create-keypair KEYNAME >KEYNAME.pem), specifying it when running an instance (euca-run-instance -k KEYNAME), and then logging in using the key generated (ssh -i KEYNAME.pem root#INSTANCE-IP). You'll probably have to change the permissions on that .pem file before SSH will allows you to use it (chmod 0600 KEYNAME.pem). The instance obtains the public portion of the key from the cloud at boot time and adds it to the authorized_keys file.