I am trying to run a WMIC command under another user.
I do not have their password but i have admin access on the machine, is this possible?
Its simply to export mapped drives etc for backup purposes.
Mapped drives are stored in HKEY_CURRENT_USER. 99 times out of 100 it is just easier to run a script from the user's context (say, a logon script) that writes their mapped drives somewhere.
Related
I need to create tools so that a non-experienced/non-technical users can use (which means connect and start/stop) a Virtual machine on Azure. For connection, the RDP connection is doing a good enough job and is easy to take a hand-on. On the other side, to start / stop a virtual machine you normally need to access to the Azure portal which (on top of being not straightforward for a non-technical user) causes some access policy problems. One option could be to just let the virtual machine always "on" but then we are billed for 100% of time even though the user only needs it for a couple hours a week.
That's why I investigated the possibility to create a script that could be put into an executable file that would launch automatically the virtual machine by just clicking the exec. I have already seen this stackoverflow question :
Start azure virtual machine without azure portal
which suggests to create an Azure PowerShell script that would start the virtual machine. Only problem is that launching a powershell script is out of the technical level of the person who would use it. On top of that, there is a need to install Azure add-on for powershell (if I understand correctly) which would not be possible depending on the machine and the rights the user have on it.
So my question : Do you have any idea on how I could make a simple program (in the form for example of an executable that would run on any machine without any dependency) that would start an azure virtual machine ?
One solution I thought about but it seemed very complicated : create a "super low cost" virtual machine that would be on 100% of time and just create an exec that instruct this VM to start the other virtual machine on demand ?
Thanks for your help
I have a problem with the idea that a powershell script is outside of the scope of a user that can run an exe file. If built properly, a ps1 should just be a double-click, exactly like an exe.
Aside from that, you have a couple hurdles to look at.
Your user can't have access to the resources that they need to interact with.
This can be done by passing custom PScredential objects through the script and pulling the credentials from a file. You would build the credential file with ConvertFrom-SecureString and then import it in with CovertTo-SecureString. The biggest problem with this is that if the user can see where that file is stored, they could potentially write a script to access that file and gain privileged access.
Your user doesn't have permission to run the powershell resources needed to execute the script. For this, you'd need to build in runas permission on the script, and I think creating an exe might be the best avenue for that. Although you could have the initial script call another shell with elevated permissions and work through that.
There are tools out there like PowerGUI, that will compile a ps1 file into an exe format. A properly compiled and secure exe file would hide the scripts that call out to secure string files and also allow for custom runas permissions built into the program.
What I want to do is to process some batch jobs involving scripts or programs that may unexpectedly perform destructive operations (like doing recursive delete on the "/" dir). The scripts and programs are written by amateurs, who are very likely to do stupid things.
To prevent my OS from being destroyed, I want to restrict file access permissions on a certain directory for each job. I do not want the job script or executable to be able to write or delete anything outside their assigned directory (including the directories assigned for other jobs, I don't want any job to disturb the result of others).
Currently, I thought of two plans:
One is to use chroot on executing the jobs. But when using chroot, I will not be able to access bash utilities or other installed programs such as ffmpeg. This is not acceptable for my script jobs.
The other is to create a user for each job, and run jobs as a certain user. But by this way, I would have to create thousands of users; cleaning up would be a great headache.
I'm pretty much prefer the second idea, but I'm seeking for a way to avoid creating so many users and having to delete those users afterwards.
Put all the tools you need inside a directory and then chroot into it perhaps?
The second option is fine too. You don't have to create many users. Just one or two and all the scripts can run as them.
Third and probably the best is to spawn off a VM and just ssh into it and run the scripts. If the VM gets ruined, you can always spin up another one.
How do your users access your computer?
Do they have to be root? because otherwise they won't be able to recursively delete /...
Anyway, if it's through ssh, you could configure a separate write-only chrooted environment, like:
sshd_config:
AllowGroups trusted users
# all users gets chrooted to a directory
ChrootDirectory /srv/jail
# users from a certain Unix group (let's call it "trusted") get chrooted to /
Match Group trusted
ChrootDirectory /
fstab:
# mount-bind non sensitive directories (ie.: `/tmp`, `/home`) in read-write
/srv/jail/home /home home bind 0 0
/srv/jail/var/spool/mail /var/spool/mail mail bind 0 0
# you mount-bind sensitive directories in read-only
/usr /srv/jail/usr usr bind 0 0
/usr /srv/jail/usr usr bind,remount,ro 0 0
# etc.
I would personally advice against Docker...
I have created a web application where user can run Java code in the browser.
I am using chroot for executing user submitted code in the web server.
In the chroot script I am doing mounting and then unmounting some required directories.
this works very well normally but when I fire that executing requests in a row like
20-30 requests, then for some response I am getting this message /bin/su: user XXX does not exist where XXX is username for the Linux system where I am mounting the required directories.
While for others I am getting the expected output result.
My concern is "is there any side effect of doing mount and unmount repeatedly in the Linux box?
Or is there any setting in the Linux to make this config to support?
In order to use /bin/su you need to have the user information provided by /etc/passwd. Have you mounted that directory or (as I would recommend) copied it to the /etc/ in the new root directory?
Concerning your mount issues, yes, mounting and unmounting can take some time and is not guaranteed to be instantaneous (especially the unmounting can plainly fail if something is still active on the mounted file system). So maybe you should check if the unmount failed and retry in that case.
Thanks for the reply...Yes you are absolutely right Alfe! it is the problem of mounting/unmounting in a row. I have checked this by SSH login to my web server. when I executed 20-30 program commands repeatedly(separated by semicolon) then I got the desired output in a sequence on my window . then I opened another SSH window and again I executed 10 commands from that window and 20 commands from previous window . when I saw the output then for some commands in both the windows I got that message of "/bin/bash user XXX doesnt exist". so one conclusion is that when I make web requests concurrently then execution of commands(chroot/unchroot) are not in a sync. that's why I am getting this message. I am not very good in Linux . I don't know How can I address this issue.
Related to my question: "How can I configure Cassandra to create files with custom rights?". I'm trying to approach the problem from the OS level.
Given two different Linux users - cassandra and tomcat7 - can I give tomcat7 read access rights to all the files which have read access rights by cassandra? The files are only o+rw (so I can't play around with groups); Cassandra keeps creating new files all the time so setting the group permissions manually isn't an option.
You could try changing the default file permission of the cassandra user using umask, assuming the mask isn't hard coded into Cassandra. This would allow you to add tomcat7 to the default cassandra user group with read/write access.
Somewhere in the shell profile or other config file for cassandra there is likely to be a line referencing umask with a setting of 077 or 0077. Replacing the first 7 with a 0 will allow rw for the group on all new files created. It is likely to be in the shell profile as it has it's own user, but it is sometime part of an application configuration file. You will of course need to change the file permissions of existing files, but this should be trivial.
The man pages don't do a brilliant job at explaining the ins and outs of the umask, but there is a nice tutorial on Understanding umask settings on Nix Craft. However, to guard against link rot, googling "linux umask" chucks up a whole bunch of tutorials from everyman and his dog.
There are two ways to do this
1) alter the uid in the password file to be the same for cassandra and tomcat7. Add cassandra and tomcat7 to the same set of groups
To show this actually works
a) add a user, I used the command
sudo adduser likeme --shell /usr/bin/zsh
I added a different shell so it is immediately apparent that this entry is being used
b) alter the uid in the /etc/passwd file. I used this command and edited the file so that the uid for my normal login (jamie) is used as the uid for the new user.
sudo vipw
c) test the new user. Here is what happens
$ who am i
jamie pts/10 2013-11-06 19:04 (:0.0)
$ sudo su - likeme
%
Note the prompt has changed because a different shell is being used. However:
% id
uid=1000(jamie) gid=1000(jamie) groups=1000(jamie)
It still says I am me!!
This is because in a fundamental way the two users are the same. You might say that there are two usernames but only one user.
2) configure sudo to allow tomcat7 to become cassandra
tomcat7 ALL = (cassandra:cassandra) ALL
Assuming you are also interested about non-system users which are supposed to be allowed to act as the other user, I would just allow him to log on as the other user.
If you are reluctant to just give him the password of the other user, then you can allow him to log on via ssh (locally) and pre-shared keys. For this, generate a key (ssh-keygen), store it in ~cassandra/.ssh/ and put the public part also in ~tomcat7/.ssh/authorized_keys. User cassandra should then be able to just switch to the other user using ssh tomcat7#localhost.
I've this need, I have to install ubuntu on a machine for a specific purpose, and I have to create a particular locked user account.
On startup i need to display the login box (so I have to admin the machine, only reboot and login as root) in the format with username and password fields.
After the login of this user, I have to auto open Google Chrome on a specific page.
Stop, this specific user doesn't have to do more. This machine is connected to a display with show ads in the expo of my client.
How to do this? I don't have any idea. Can anyone tell me ALL the correct step to achieve this?
Thanks in advance, Francesco
You have to setup a kiosk mode. You can find a good tutorial and all needed steps at http://www.alandmoore.com/blog/2011/11/05/creating-a-kiosk-with-linux-and-x11-2011-edition/
This may be an "old hat" answer...but yes, it's pretty common in practice to simply create a login shell that does a specific task (kind of similar to FTP or backup user accounts).
This means - simply put - in the /etc/passwd where you normally put the shell for the user (/bin/bash or whatever) you actually put a script that does whatever you want it to. When the script ends, the user is booted off.
If this is combined with a properly configured selinux, its pretty safe as long as the script is not hackable (I.e. does not request input which can have appended commands (I.e. "input name:" Mike; rm -rf /) or that can lead to a buffer overrun.
For this reason, its good practice to put the script in an isolated directory, chroot the user, put the user in its own group, and have the user/group only have permissions to that dir.