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.
Related
I am currently building a sandbox environment utilizing docker where all users will be directly guided into a docker container with home dir linked as data vol upon login. This is achieved through the use of a custom user shell instead of /bin/bash csh etc.
However, scp/rsync/sftp fails with this custom shell unfortunately. My current solution is to make a separate no-login account with the same home dir as the sandbox user and only allow scp/rsync/sftp through rssh in this account where users can then upload their data.
Just wondering if I can streamline this process somehow and use only 1 account to redirect users into docker containers directly AND allow sftp/scp processes as well?
Thanks!
Edit:
upon more poking around, I have discovered that the newest sshd internal-ftp-server subsystem do not invoke the users login shell, and I can enable sftp this way. However, i dont think rsync and scp works this way unfortunately.
The ultimate goal i want is basically to be able to sandbox users directly into a container upon login and to allow sftp/scp/rsync upload ideally using the SAME credentials instead of setting up a separate one for them.
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...
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.
Conducting a user account cleanup accross Solaris and Redhat linux systems, many of which have a number of Samba shares.
What preference do people have for creating the local unix accounts for non interactive Samba users? In particular, the shell entry:
noshell
nologin
blank
And why?
JB
I have seen the shell set to the passwd command so that logging in only gives an opportunity to change the password. This may or may not be appropriate in your non-interactive user case, but it has the upside of allowing people to change passwords without bothering an admin.
I've always thought /bin/false was the standard. Some ISPs use a little menu system that lets them change their password / contact / finger info, check usages, etc. Whatever you use, you may want to add it to your /etc/shells file as well if you want the user to be able to use FTP for instance, as some services will be denied to users who are not using a shell listed in that file.
I usualy send all mine to /dev/null that way I don't ever have to worry about it.
I have known some people who set it to /bin/logout so that when someone logged in they were logged back out.
Don't do blank. That runs /bin/sh.