I wonder if it's ever possible to 'secure' wine; like for a user not being able to delete 'explorer.exe' or mess with the dll's.
I've heard of apparmor (i'm running ubuntu), and chroot.
What would be the best method ?
How about this: set the files to a different user (chown), and set the "group" and "other" rights to "read only" (chmod 644).
That way, the current user can only read the files, but not modify them.
You can use the filesystem permissions of the host OS to "secure" the files.
Related
I sometimes have a need to pay someone to perform some programming which exceeds my expertise. And sometimes that someone is someone I might not know.
My current need is to configure Apache which happens to be running on Centos.
Giving root access via SSH on my main physical server is not an option.
What are my options?
One thought is to create a VPS (guest as Linux) on my main physical server (operating system as Linux) using virtualbox (or equal), have them do the work, figure out what they did, and manually implement the changes my self.
Seem secure? Maybe better options? Thank you
I suggest looking into the chroot command.
chroot() changes the root directory of the calling process to that specified in path. This directory will be used for pathnames beginning with /. The root directory is inherited by all children of the calling process.
This implications of this, are that once inside a chroot "jail" a user cannot see "outside" of the jail. You've changed their root file. You can include custom binaries, or none at all (I don't see why you'd want that, but point being YOU decide what the developer can and can't see.)
We can use a directory for chroot, or you could use my personal favorite: a mounted file, so your "jail" is easily portable.
Unfortunately I am a Debian user, and I would use
debootstrap to build a minimal system to a small file (say, 5GB), but there doesn't seem to be an official RPM equivalent. However the process is fairly simple. Create a file, I would do so with dd if=/dev/zero of=jailFile bs=1M count=5120. Then we can mkfs.ext4 jailFile. Finally, we must mount and include any files we wish the jailed user to use (this is what debootstrap does. It downloads all the default goodies in /bin and such) either manually or with a tool.
After these steps you can copy this file around, make backups, or move servers even. All with little to no effort on the user side.
From a short google search there appears to be a third party tool that does nearly the same thing as debootstrap, here. If you are comfortable compiling this tool, can build a minimal system manually, or can find an alternative; and the idea of a portable ext4 jail is appealing to you, I suggest this approach.
If the idea is unappealing, you can always chroot a directory which is very simple.
Here are some great links on chroot:
https://wiki.archlinux.org/index.php/Change_root
https://wiki.debian.org/chroot
http://www.unixwiz.net/techtips/chroot-practices.html
Also, here and here are great links about using chroot with OpenSSHServer.
On a side note: I do not think the question was off topic, but if you feel the answers here are inadequate, you can always ask on https://serverfault.com/ as well!
Controlling permissions is some of the magic at the core of Linux world.
You... could add the individual as a non-root user, and then work towards providing specific access to the files you would like him to work on.
Doing this requires a fair amount of 'nixing to get right.
Of course, this is one route... If the user is editing something like an Apache configuration file, why not set-up the file within a private bitbucket or github repository?
This way, you can see the changes that are made, confirm they are suitable, then pull them into production at your leisure.
I need to allow my local webserver (localhost) to read and write the /etc/network/interfaces file on a linux system (ubuntu).
The data manipulation of the file is done, I just need to know the best way of granting www-data the permission to do it.
I guess I could first log in as root and set permission for all to edit the file (not a big security risk since it is a mediaplayer and won't be accessed by any other user).
I could also do some nifty grouping of the user, I guess... not so seasoned with these linux things.
Anyone have a good suggestion, or input on why my suggested method is bad?
I don't know why would you want to do this, but generally groups are handy for this:
You create a new group, for example networking
then you change the group of the file to this new group (and check that it has g+rw permission)
finally you add www-data user to the networking group.
(And possibly relog, since permissions are often cached; this may not be needed for www-data)
Just wondering for an idea if it would be possible for a filemanager like xfe, rox, nautilus to be able to run (at launch) with chroot aka not being able to go down the tree.
I would be interested if anyone has an idea on how to do so; it's for a cybercoffe where I don't want people to access other directories.
(solution except using linux fs permission).
Your file manager will need to see and access of the special files you are trying to hide (such as /proc content and /dev content) in order to work properly.
So yes, you can run a file manager in a chroot, but you need to put (a minimal version of) /dev/ and /proc in the chroot for it to work.
I would either hack the source of the file manager to hide what you want or go all the way and run the file manager in a virtual machine so no damage can be done by end user to real computing resources. qemu/kvm is excellent for that.
What's wrong with using permissions? Generate a temp user on login, give them write access only to their homedir. Anyone who would try to hack your system is not going to have trouble getting around whatever roadblocks you have in place. THey'd probably start by firing up an xterm anyway. Besides, security through obscurity isn't.
we do:
useradd -s /bin/rbash -d /home/dir/user1 -m user_1:user_1
rbash is not even a solution because you can browse all files with midnight commander.
then we create user_1.domain.com we assign this vhost user_1:user_1 our whole point is to disable this user poking into server's other directories.
How do we do it?
is chmod o=- -R / a feasible solution to user restricting?
this doesn't answer my problem.
How to restrict SSH users to a predefined set of commands after login?
First off, read access to the server's "other directories" is generally required. That's where the binaries and data files for the installed software live, after all.
If you want to disallow access to other users' directories, you can always set default umasks such that only owners have read access and let the users decide what to enable for world readability. Or similarly, place every user into their own group, which is the default on most linux distros.
If you want to disallow access always, without the possibility of turning it on, you can play tricks with MAC tools like AppArmor (simple) or SELinux (complicated) to do that. Though this has significant administrative costs you need to think about.
It used to be that chroot was a common solution for this kind of problem, but that's fallen out of favor in recent years as it doesn't quite isolate things as much as you would expect.
Finally, the "proper" solution to user isolation is generally felt to be virtualization, either full-system stuff over vmware, kvm, xen, etc... or single-kernel solutions like BSD jails or Solaris Zones.
Given the dangers of SUID shell scripts, is there a more secure way of giving passwordless access to scripts (bash, PHP) with root permissions in Linux?
(Ubuntu 8.10)
You could consider sudo.
Although not 'passwordless', it doesn't require the user to be given the root password. It can also provide an audit trail of use of the script.
edit: as per comment from Chris, there is an option not to require a password at all for certain commands, see here for details. It can also be set up not to prompt excessively for the password, i.e. one entry of the password can be good for multiple commands over a period of use.
By the way, sudo is built in to Ubuntu and nicely integrated with Gnome. When ubuntu prompts you for your password to do privileged operations, that's sudo under the hood.
Be sure to review the "PREVENTING SHELL ESCAPES" section of the sudoers man page if you go the sudo route.
I would recommend sudo. Be sure to tighten your sudoers file appropriately; and yes, you can allow some commands to be executed with no password being requested.
Configuring sudo to let normal users run shell scripts with elevated privileges isn't any better from a security standpoint than making the script suid root. All the pitfalls still exist.
Instead you should write a proper program that does extensive security checks. Some points to consider:
Don't write it in C, you'll shoot yourself in both feet.
Check all inputs.
Drop privileges as soon as possible.
Keep it short.
Since sudo has already been mentioned, you might want to consider various sandboxed environments, depending on your needs — e.g., jail or similar.
For a really heavy-weight solution, consider a MAC (Mandatory Access Control) system, like SELinux, AppArmor, TrustedBSD etc.
To improve security consider whether it is possible to do the operation as a special user or group, which has exactly the access rights needed for it. Then you can make the script setuid/setgid for that user or group.
If the use case is a machine running under VirtualBox and security isn't really an issue, you just want a light barrier to prevent yourself shooting yourself in the foot, what then? (Then the security arguments don't really make sense, since it doesn't matter if the machine gets compromised by an outsider who can't see it anyway due to the way VirtualBox insulates it via NAT.)