Our IT manager and I (Linux beginner) had a discussion in our company about how to keep employees from running programs they bring on USB sticks into the company.
He said it’s cumbersome to prevent that under Windows XP, which we use.
My system is an openSUSE 11.4. (only one in the company. I wanted it.). I said Linux should be better equipped to guarantee a save system.
As proof of that I wanted to download a Linux program and show that it does not run without root allowing it to.
I downloaded an installation program shell scrip for some program (something like install.sh).
The strange thing though was, that I could run it WITHOUT setting the “is executable” flag as a regular user. It ran just like that and installed whatever it wanted to install.
Not safe, it seems.
I opened Dolphin and saw the flag was not set for this install.sh (under “Permissions”). So I set it. Then I reset the flag to “not set” = “is not executable”. Only now I was unable to run that script. Strange.
If there anything I overlooked?
Can you really run install programs under Linux w/o being root? In that not unsafe?
How do you prevent that?
Thanks for your help (and please forgive me for this probably idiotic question).
You are wrong. Users can always install and execute programs in directories they have write permission on. Maybe they have to change the permissions, but that is also allowed. In any case a shell script can always be run with sh script.sh.
What a user cannot do is write on files or directories they do not have permissions for. Thus the system prevents users from endangering other users files (provided those users are wise enough to not trust other users). It does not prevent users from executing their own programs.
Too bad. Since I am sitting in a network with read access to other user’s directories, a hostile script that I run (maybe by mistake or malicious intent…) could read everything in their directories. Not write, but read, but that’s bad enough. That script could also change stuff in my home. Is there no way to protect stupid users from doing this?
You are always allowed to shoot yourself in the foot on your own machine :), but for a shared machine, there has to be some responsibility. I mean would you let this kind of person on your system:
cd
nano supersecretdepartmentplans.doc
chmod a+r supersecretdepartmentplans.doc
chmod a+rx $HOME
or the equivalent using the GUI?
Personal machines may be a waste of CPU cycles, but at least most people have a vague notion of physical security whereas Linux permissions can be abstract to them.
I normally leave things readable by all. I have some subdirectories that are not publicly readable, and I put some private stuff there. And some other private stuff is encrypted.
It is a problem because sensitive company files are in those public directories that I (and a malicious script that could I run) could see and send somewhere. Sure, we also each have private directories, but a lot of stuff is - and has to be- accessible by all employees.
I understand that preventing users from running a shell scrip is probably impossible, but that leaves a security hole open. I had hopes of getting more Suse installation in our company, but this argument, which I had hoped would make a difference, does not work. :’(
They will want to use their own word processors and programs anyway. Promote Linux as a good Samba server and you can set up various shares for different groups of people and with more fine-grained access than Linux permissions allow. A perennial problem in Linux is how to allow a user in a group to create a file that is modifiable by other members. In Samba that is not a problem.
At my school our home directories are mounted with NFS to the file server. But the noexec option is specified in fstab for that mount so we can’t execute anything in our home directory.
the stick you ‘installed’ from is fat (right?) and if you looked at it
in a command line program like mc, you would have seen that everything
looks executable to a fat file system…
but, if you execute a script as yourslef, it will ‘install’ in your
/home, and NOT into the system…because it can’t write to the system
directories without root powers…
see, as a user you are allowed to install anything you wish into your
home space…you just are not allowed to mess up the system…see?
hint for next time: dry run your examples before you try to convince
‘the boss’ how much better FOSS is…he will be hard to convince even if
your presentation is air tight…and, VERY hard to get to pay attention
if you fail…i mean, most bosses think super-rich Bill must be
right! right?
uwekremmin wrote:
> It is a problem because sensitive company files are in those public
> directories that I (and a malicious script that could I run) could see
> and send somewhere. Sure, we also each have private directories, but a
> lot of stuff is - and has to be- accessible by all employees.
Let me get this straight. All employees have to be able to access “lots
of stuff”, but you mustn’t be able to see it? How’s that supposed to work?
> I understand that preventing users from running a shell scrip is
> probably impossible, but that leaves a security hole open.
No it doesn’t, it means that you don’t understand how security works and
what it’s trying to do.
I think you may be under the misunderstanding that shell scripts are something magical that can bypass permissions. They can do no more and no less than what the user can using existing programs. So it doesn’t matter re security whether the user can run shell scripts. Anything that must be kept private must be given the appropriate permissions and anything that has to be shared also must be given appropriate permissions. What gets complicated is when you have different groups of users and various combinations of permissions for different groups. It’s hard enough for an experienced user to work out the appropriate permissions for all groups, and some things, like owner create but group write are very hard/impossible to arrange with standard Unix permissions. With exported shares it is much easier to model.
On 04/18/2011 02:36 PM, uwekremmin wrote:
>
> Is there no way to protect stupid users from doing this?
of course there is! the way is called a System Administrator, smart
enough to not give all users the ability to read other user’s
directories, etc etc etc etc etc etc…
now, if all you have are users (with one or more trying to be a
learn-on-the-job-by-trial-and-error System Administrator), and all you
done is install an iso image and give everyone an account…THEN you
might as well go ahead and give every one the root password…and, make
it the same root password on every machine…just to make it easy for
everyone to pretend it is a Win3 Redmond set…
or, just let’em keep pay big money for the M$ version of insecure
off-the-shelf…
yes, most Linux distros are “more secure” out-of-the-box than is MS, but
the real difference is (in addition to ring-in-the-nose and cost) is
that Linux can be REALLY safe…without spending another fortune on
add-on security–which can’t really make it safe, it just patches up the
known holes, as they are found…
Yes, I probably don’t understand security. (Like 90% of the population, I’m tempted to add )
But why does it NOT leave a security hole open?
If I am allowed to run a hostile script, it can send my sensitive files to anywhere. How do I prevent that?
The problem is not the script, the problem is the lax permission. Even if you were to somehow prevent users from running scripts, they could still use existing programs to grab unprotected information.
I had hoped to find out if it is possible to prevent users from running scripts (which could do harm to their files).
But it obviously isn’t. Or my IQ is insufficient to state that question more clearly.
Most PC users (me included) are idiots re. security. They have to be protected from themselves (as any admin knows…).
Protecting them from running scripts they got from who-knows-where, seems not possible.
)