I need to get a hold of web-server logs by regular users who have /bin/bash as their shell enabled. Logs are stored in a directory which has drwx------ permissions and is owned by root:root so obviously they can't access any files in it (and yes, I can't really change this permissions setup).
The system(s) is Debian Linux. So I'm looking for some wrapper script, it might not be bash exactly, which, in my vision, will do the following:
you pass one argument to it - a sitename - i.e. site.com;
it greps all the lines containing this site.com;
stores the result to user home dir.
This part is easy, the real problem arises when you want to bypass restrictions yet to stay (at least somewhat) safe. So:
script must only be started after password is provided for it to be run;
in case of bash scripts they are run with permissions of the user account who ran it - so my guess is it should have su -m root -c 'grep ...' in it, but I found no way how to pass password to the prompt inside the script so far (sudo is not exactly suitable unfortunately);
if there is a way to pass password to su from inside the script then of course script itself must have permissions 751 and owner of root:root - so that the end user who runs the script (or anyone else) won't be able to see the script's content.
I'm open to suggestions how this should be done or if it's should be done at all (at least this way) :) Thank you.
Given what I understand of your needs, I summarize here the various options that come to my mind. In no particular order:
Use sudo together with a policy file (/etc/sudoers -- edit with
visudo) to restrict the commands available to the user
Use a cron job (more or less smart) to collect data on the server at regular
intervals and store them at a location accessible to you (or mail them to you...)
If you have administrative access to the server, you might create a special user with
the "log-grepping" tool as connection shell (/etc/passwd)
If you have ssh access to your server, you may also use the
authorized_keys file on the server to restrict remote command over ssh
Those are only general directions. Read about them. Try them. And if you're struggled, don't hesitate to post an other question!
As a last word, as it has already been stated in a comment, please refrain yourself to develop your own "security restriction system". sudo, ssh, pam (and probably others ... selinux?) have been specifically crafted for that purpose...
Related
I am looking to write a script which does following
List item
As I run it, it should ask for sever entry(linux or AIX)
Once it is provided, I should be able to login into it with sudo access
Then it should run command from particular location and display the output.
I have been looking for this entire day on this site, but could not find the satisfactory answer.
Hope to get good response on this.
Thanks
Abhi
There are a couple of ways to do this. As Leo pointed out, you could use Tcl/expect. This tool allows you to emulate a user and interact with programs as if you were at the keyboard. You can provide passwords to login clients and so forth. It's a bit involved and sometimes not so reliable. If you're using ssh to log in, it might be easier depending on your skills just to use your favorite shell script and use pre-exchanged keys for logging in. If you do an ls ~/.ssh in the directory of the system you're logging in from (running the script), you may see a file called id_rsa.pub or similar. If not, you can use ssh-keygen to create one. Then create or edit the file ~/.ssh/authorized_keys on the machine you're logging into. Append the contents of this file (id_rsa.pub) to authorized_keys. This should allow you to log into that user from the other machine without a password (note: This could be a security risk!). Then, you can use the command ssh user#dest -C remote_command to execute your command, obviating the need for expect.
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.
I am writing script which contains smbget -u user -p password smb://host/share/file command. Is there any way to hide password parameter in this script? Script will be used on computer which is shared by multiple users. I want to give them opportunity to download file without showing my password.
The comment provided by Marc is correct. You can work around the problem by using mount.cifs (possibly via AutoFS if required) and taking advantage of the credentials option during mount - that option allows you to store the password in a non-user readable location.
mount.cifs //some/server /mnt/somewhere -o credentials=/root/credentials_file ...
Your script could mount this location and retrieve the file for the user (or just give the users access to the location). You'd need to have an appropriate entry in your /etc/fstab file or configured with AutoFS to make it work with your script.
An alternative would be to write the script using something which can be compiled - it's not secure for a number of other reasons, but might fit your bill.
I would like to use a callback feature of an SVN repository (Unfuddle) to ping a URL on my server whenever a commit has been made. I have a PHP script accepting the message and attempting to call a shell script to execute an 'svn update'.
The problem I'm facing is that Apache is running under user 'www-data' and does not have access to the local repository: '.svn/lock' permission denied. I have read all about setting SUID/SGID on shell scripts and how most *NIX OS's simply don't support it because of the security risks involved.
However I can set the SUID/SGID bit on the SVN binary file located at /usr/bin/svn. This alleviates the problem by allowing any user to issue SVN commands on any repository; not the most ideal...
My question is what's the most logical/sane/secure way to implement this type of setup and if I did leave the bits set on the svn binary does that open up a major security risk that I'm failing to realize?
Sorry for the long-winded post; this is my first question and I wanted to be thorough.
Thanks
There are 2 types of solutions for this kind of problem, polling or event driven.
An example of a polling solution would be to have a cronjob running on your server updating every N minutes. This would probably be the easiest to maintain if it works for you. You would sidestep the whole permissions issue by running the cron from the correct account.
The solution you covered is an event driven solution. They are typically less resource intensive, but can be harder to set up. An another example of an event driven solution would be to have www-data belong to an svn group. Set the SGID bit and chown the repository directory to the svn group. This should allow anyone in that group to check-in/out.
If you need to limit to updating, you can escalate privileges or change user temporarily. You use ssh single purpose keys (aka command keys) to ssh in as the user with the correct privileges. The single purpose key can then be used to do the update.
Another way to escalate privileges would be to use sudo -u [user] [command]. Update the /etc/sudoers file to allow www-data to escalate/change user to one that can perform the update.
Either way I would NOT use SUID/SGID scripts.
As CodeRich already said, you can set up a cron job to frequently update tue working copy(that's also the solution I would use).
Setting svn SUID/SGID is bad, because svn can write files everywhere in the file system (think of a public accessible repository containing a passwd and shadow file, checked out into your /etc). You could use a little suid wrapper program(which is SUID to your user account, not root), which chdir into your working copy and executes svn with the correct parameters there. You can look at ikiwiki which does this when it is used as a cgi.
Another way is to change the permissions of your working copy, so that the www-data user can create and write files there.
change the permissions on your working copy so that Apache can write to it. You have a directory you want to change, you need permissions to do so. Its that simple :)
The problem you then face is allowing any Apache user (or hacked page) to write all over your repo, not a good thing. So - you need to only allow a part of the system to write to it, and the best way to do that is to run your php script as the user who already owns the repo.
That's easily achieved by running the php script as a cgi, or fastcgi process. You can specify the user to use, it doesn't have to be www-data at all, though it does require a bit more setting up, you can have the best of event-driven and security as you're likely to get.
Here's a quick explanation of phpSuexec that does this.
I want to build a web based admin tools that allow the system admin to run pre-configured commands and scripts through a web page (simple and limited webmin), what is the best approach?
I already started with Ubuntu installing LAMP and give the user www-data root's privileges !!!
as I learned (please check the link) this is a really bad move !!!, so how to build such web-based system without the security risk?
cheers
I did something like this a couple of years ago. It was (I like think) fairly secure and only accessible to a limited number of pre-vetted, authenticated users, but it still left me with an uneasy feeling! If you can avoid doing it, I'd recommend you do :)
I had a database sitting between the frontend web-tier and the script which was actually executing actions. The relevant table contained a symbolic command name and an optional numeric argument, which was sufficient for my needs. This allows you to audit what's been executed, provides a quick and dirty way to have a non-www user do things, and means if the website is compromised they're constrained by the DB structure (somewhat) and the script which pulls data from it.
The data from the DB can be read by a daemon running in a separate, unprivileged account. The daemon pulls and sanitises data from the DB and maps the 'command' to an actual executable (with a hard-coded map, so commandA executes A, commandB executes foo, and anything else would get flagged as an error). The account can be locked down using AppArmor (or SELinux, I imagine) to prevent it from executing, reading or writing anything you don't expect it to. Have a system in place to alert you of any errors from either the daemon or AppArmor/SELinux.
The executables which the daemon runs can be setuid'd if appropriate, or you can use the sudoers mechanism to allow the unprivileged account to execute them without a password.
I already started with Ubuntu installing LAMP and give the user www-data root's privileges
Don't do this.
If you really want to execute some very specific scripts under root privileged. Create such predefined very limited scripts, allow their password-less execution with sudo for specific user and then run them via script and don't forget authentication.
Generally this is bad idea.
SSH is your best friend.