does firefox under ubuntu has something similar to activeX, in terms of security vulnerability?
‘ActiveX’ can be considered in two parts, the object model and the installation method. Firefox has something similar—and cross-platform compatible, Ubuntu or other—for both.
The object model of ActiveX is Microsoft COM; Firefox's equivalent is XPCOM. Many other Windows features and applications that are nothing to do with web browsing use MS COM, and there have traditionally been endless problems where COM controls that were not written for secure web usage were nonetheless available to web pages. This caused many compromises. Firefox is better off here as XPCOM is not shared with the rest of the system. Newer versions of IE have better controls for mitigating what sites are allowed to use what controls.
(As a side-issue, because many add-ons for Firefox are themselves written in JavaScript, a high-level scripting language, they are often more secure from buffer overflow and string handling errors than extensions for IE which are commonly written in C[++].)
The control-downloader part of ActiveX has also been cleaned up a bit since the bad old days when anything in the My Computer zone could install any software it liked, and aggressive loader scripts could trap you in an alert
loop until you agreed to approve the ActiveX prompt. Firefox's equivalent, XPInstall, behaves largely similarly, with the ‘information bar’ on all but Mozilla's sites by default and a suitable warning/prompt before installation.
There is another built-in way you can compromise yourself in Mozilla: signed scripts. I have never seen this actually used, and certainly there'll be another warning window appear before a script gains extra rights, but it kind of worries me that this is available to web pages at all.
for example an exploit through flash will gain access to my pc under my user rights
Yes, the majority of web exploits today occur in plugins. Adobe Reader, Java(*) and QuickTime are the most popular/vulnerable. IMO: get rid of those, and use FlashBlock to only show Flash when you want it.
(*: and Java's dialogues before it lets you give up all security to some untrusted applet is a bit bare too.)
Ubuntu gives you some questionable plugins by default, in particular a media player plugin that will make every vulnerability in any of your media codecs exploitable through the web (similar to the Windows Media Player plugin, only potentially with many more formats). Whilst I have yet to meet an exploit targeting Linux like this, that's really only security through obscurity.
Note that ActiveX itself is no different. A web browser compromise based on ActiveX still only gives user-level access; it's only because prior to Vista everyone habitually ran everything as Administrator that this escalated to a full-on rooting.
and then follow to exploit some known vulnerability in X to gain root rights. that is not "easy".
Maybe, maybe not. But I think you'll find the damage some malware can do from even a normal user account is quite bad enough. Copy all your personal data, observe your keypresses, delete all your documents...
Well, there are two separate aspects in running an application as root; one of them improves security and another one may compromise it - I think mixing those two aspects explains your confusion.
running an application as another user (possibly root user, but not necessary) makes it more difficult for another process to access files owned/created by that application and do other nasty things (send a KILL signal, for example). This is good.
if an application happen to have a vulnerability (i.e. sending it some specially formatted input makes it to execute some code via buffer overflow etc.) - then, after exploiting the vulnerability, the attacker will be able to execute code with the privileges of that process. In this sense, running an application with root privileges is BAD, because it would give the highest level of privileges to attacker.
Now you understand that running update manager as root may be bad if it contained a bug which would allow a specially-crafted .deb file to crash it and make it to execute some code. However, running some applications, such as package manager, with superuser privileges is unavoidable because they modify the essential parts of the system.
The common solution to this problem is to perform so-called "privileges drop" on program startup; this is often used to run webservers and other potentially exploitable (and accessible from outside) software. The idea is simple: the program starts as root, but as soon as possible it switches to some user account with as little privileges as possible (no shell login, chroot-ed to its home directory etc.) This way, even if compromised, it would give attacker a very limited access to the system. Also, other user accounts (except the superuser) will have no access to the application's files
I'm not sure how easy would it be to run a desktop application like this though.
Actually, in this situation I think running web browser as a non-privileged user would make more sense. And, of course, Google gives us a few links on the subject:
Taking this idea to the extreme (as you're suggesing in the comments) will give you a system which is similar to how Android works; on Android each application operates within its own user account, so it only have access to its own files. This probably have some problematic areas in Ubuntu, i.e. if you downloaded a file using Firefox running in a restricted account, it'll only be able to save it in its own home folder so it won't be possible to open the file in a text processor (which runs as another user)...
Regarding the launcher script I would imagine the script will be starting as root and invoking the applications as their respective users. The script will obviously need to be writeable by root only. Read about setuid.
Best Answer
A. Configurational options
If the block is meant to block not-so-experienced users from using certain applications, editing (a local copy of) the application's desktop file (as described in
[1]
) is probably the fastest and easiest way.Some additional things can be done to create an extra barrier and/or to prevent the fact that the user finds out too easily what we've done to block the application (
[2]
and[3]
).The set up is not fit for unattended situations with experienced users. In "home" situations with average users it will be sufficient in many cases.
1.Example for blocking gedit by editing (a local version of) the .desktop file
Copy the application's desktop file in
/usr/share/applications
to~/.local/share/applications
:Edit the file: open it with gedit (while you still can :)) by dragging it over an open gedit window.
replace the line
by:
remove the (possible) shortcuts, to prevent starting the application from one of the shortcuts:
remove the line (for the gedit example):
and the section(s) like:
From then on (after log out / log in) the user will see this message if he or she tries to open gedit from Dash, or tries to open a file that is linked to the application:
Hiding the application from Dash (optional measure)
After we made the changes above, having the
gedit.desktop
file still open, we can add an additional line:By adding this line,
gedit
will not even show up in Dash.Undo
To undo, simply remove the local
.desktop
file from~/.local/share/applications
2.Making it a bit more difficult to find out
While, after editing the
.desktop
file, the application will not show up in Dash any more, Dash search will still show our newly createdgedit.desktop
file, which might unintentionally give a hint how to escape the application block.To avoid that, we should exclude the directory
~/.local/share/applications
from Dash search and clear the search history.Open System Settings > "Security & Privacy" > "Files & Applications" (tab). Add the directory
~/.local/share/applications
to the list to exclude from search.3.(Not) using the terminal / command line
Redirecting the
gedit
command(1)
Editing the
.desktop
file prevents using the application from Dash, but if the user knows the AltF2combination and the command to run the application, he or she will still be able to start the application, just like with the terminal. A nice and easy to set up extra measure is to create (if it doesn't exist yet) the directory~/bin
and create a small script in the directory:Make it executable and name it after the application;
gedit
in this case.Since
~/bin
is inPATH
, running the command will call the script instead of the "real"gedit
application. As a result, the sameYou are not allowed to use this application
-message will appearRedirecting the
gedit
command(2)
Another way (with more limited effect, see note) of redirecting the application's command is to add an alias to the
.bashrc
file:add the line (gedit example):
Note: this is only to be used as an extra measure, since it only prevents the application to be called from the terminal directly. Double clicking on a (e.g.)
.txt
file will however still open the application.Make the use of terminal difficult or impossible at all
To prevent the use of the terminal, you can also do the same trick on the
gnome-terminal.desktop
- file as in[1]
, and/or change the default shortcut key combination to run the terminal (System Settings > "Keyboard" > "Shortcuts" > "Starters")4. A small tool to automatically create (or undo) an edited version of the
.desktop
file (as in 1.)If you run the script below with either the argument
block
orunblock
(you must run it with either one), you will be presented a list with (global) desktop files, representing your installed applications:Pick one, and your application is blocked or unblocked, depending on the argument you run it with.
Note
You may have to log out / log in to make it work.
The script
Copy the script into an empty file, save it as
block_apps.py
and run it by either:or
B. Scripted option(s)
Blocking certain applications can also be done by running a script in the background. The script would have to take certain actions if one of the "forbidden" applications is run.
1. Script to manipulate the screen when forbidden applications are used.
The script below offers a flexible way to block user defined applications. It runs with a simple command, with the forbidden applications as an argument, e.g. (assuming you made the script executable):
The advantage of blocking applications like this is that it is flexible; even within one account, different settings can be used, simply by using other applications as argument.
What it does
By un- commenting one of the lines:
or
The script either:
blacks the screen (
action = "xrandr --output "+screen+" --brightness 0"
):or turns it upside down (
action = "xrandr --output "+screen+" --rotate inverted"
):(who said Unity doesn't allow to put the launcher on the right?)
The script
How to use
block_apps.py
, make it executablerun it by the command:
Important
To kill the
block_apps.py
script and restore "normal" settings, use the script below (make it available under a shortcut key combination):As always with scripts, copy it into an empty file, save it as
kill_blockapps.py
, make it executable and run it by:You will probably want to have this one under a shortcut key: Choose: System Settings > "Keyboard" > "Shortcuts" > "Custom Shortcuts". Click the "+" and add the command as above.