I want to block the web browser (Firefox) from accessing just two or three URLs on just one user account. I don't want any blocking on my own account. I don't want any content filtering, or spam or malware blocking. Firefox has a couple of add-ons that are supposed to do this, but they're neither free nor open-source. As far as I can tell, filtering via a proxy server can't be made user-specific. DansGuardian looks like overkill for something this simple. All I want is some sort of blacklist function for Firefox. Suggestions?
Announcement
Collapse
No announcement yet.
Block URLs in browser? [SOLVED]
Collapse
This topic is closed.
X
X
-
Re: Block URLs in browser?
You can use the /etc/hosts file to do that, along with a little script addition in /etc/rc.local.
As root copy /etc/hosts to /etc/hosts.noblock (sudo cp /etc/hosts /etc/hosts.noblock)
Edit /etc/hosts as root (kdesudo kwrite /etc/hosts)
127.0.0.1 thedomainnameyouwantotblock.com
127.0.0.1 anotherdomainnametoblock.org
" "
and "save as" /etc/hosts.block
That gives you three files:
/etc/hosts (the original - will get overwritten by one of the two below)
/etc/hosts.block (has block commands)
/etc/hosts.noblock (the original )
Edit /etc/rc.local and just above the "exit 0" line add
if [ "$USER" = "youracctname"
then
cp /etc/hosts.noblock /etc/hosts
else
cp /etc/host.block /etc/hosts
fi
When you log in the /etc/hosts file will not block any site from you. When anyone else logs in (to another account) they will not be able to see the sites you've put into /etc/hosts.block because the domain names are routed to 127.0.0.1
You may want to get the IP addresses of those sites and add blocking lines for them too, in case someone gets clever and enters IP addresses of the forbidden sites into the browser URL. For example:
127.0.0.1 222.223.224.225"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
- Top
- Bottom
-
Re: Block URLs in browser?
Arist, I meant to quote your reply but deleted it instead.
Would you repeat your reply, specifying your implementation problem? Thanks."A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
- Top
- Bottom
Comment
-
Re: Block URLs in browser?
That's OK: I can probably make the problem clearer with a rewrite.Originally posted by GreyGeekArist, I meant to quote your reply but deleted it instead.
Would you repeat your reply, specifying your implementation problem? Thanks.
Here's what I have in rc.local:
When I boot up and log on as arist, the file rc.local_ran_successfully is created, so I know rc.local is run. But hosts has the content of hosts.block. Same result if nonarist logs in. If I rewrite rc.local so:Code:if [ $USER = arist ]; then cp /etc/hosts.noblock /etc/hosts else cp /etc/hosts.block /etc/hosts fi touch /var/log/rc.local_ran_successfully exit 0
then hosts has the content of hosts.noblock, whether arist or nonarist logs in. It seems the "if" condition will always be false.Code:if [ $USER = nonarist ]; then cp /etc/hosts.block /etc/hosts else cp /etc/hosts.noblock /etc/hosts fi touch /var/log/rc.local_ran_successfully exit 0
I modified rc.local to test it after login:
and saved it as rc.local.test. I did this because the "cp" commands in rc.local must be run as root, but if the user is root, the "if" condition will again be false. So then I runCode:echo The user is $USER if [ $USER = arist ]; then echo Yes, the user is arist else echo The user is someone other than arist fi exit 0
and getCode:sh /etc/rc.local.test
When I switch users and log in as nonarist, running rc.local.test yieldsCode:The user is arist Yes, the user is arist
This tells me that after I'm logged in and KDE is running, the script will run correctly, executing the "if" command when the condition is true. It doesn't execute correctly at bootup. From this I speculate that rc.local runs before the USER environment variable is set. Could I be wrong about that?Code:The user is nonarist The user is someone other than arist
I've also tried it with double quotes in the "if" statement, and it made no difference.
The other thing I mentioned in my reply is that rebooting is necessary to get rc.local to run, so even if I could get it to work it would be a tad inconvenient.
- Top
- Bottom
Comment
-
Re: Block URLs in browser?
I believe that the correct syntax for the IF test in the case of a string equality comparison is:
if [ "$USER" = "arist" ]
jerry@vgnfw140e:~$ echo "$USER" = "jerry"
jerry = jerry
jerry@vgnfw140e:~$"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
- Top
- Bottom
Comment
-
Re: Block URLs in browser?
My bad... I didn't think it through before I snapped out an answer. Perhaps this approach may work.
Create a script similar to this and save it in /bin with root:root and 711 permission:
Then add the following lines to /etc/sudoers. (NOTE: YOU MUST edit /etc/suders with a special editor called visudo as root: sudo visudo. You may recognize "visudo" as pico but it is special in that it copies /etc/sudoers to /etc/sudoers.tmp, whiich is what is really being editied. When you exit visudo it will save the results as /etc/sudoers.tmp but then copy that file as /etc/sudoers)#!/bin/bash
if [ "$1" = "arist" ]
then
cp /etc/hosts.noblock /etc/hosts
else
cp /etc/hosts.block /etc/hosts
fi
exit
arist ALL = NOPASSWD: /bin/iftest.sh
otherguy ALL = NOPASSWD: /bin/iftest.sh
This allows arist and otherguy to run /bin/iftest.sh using sudo without a password, but only /bin/iftest.sh.
Then, to run the script as the user from rc.local add before the "exit 0" line:
sudo -u $USER /bin/iftest.sh $USER
or maybe $LOGNAME in stead of $USER.
This approach assumes that only one person accesses the PC at a time. IF two people where in their accounts at the same time the one who logged in last would set the hosts file.
"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
- Top
- Bottom
Comment
-
Re: Block URLs in browser?
Still no go. I seriously doubt that any solution using rc.local and the environment variables $USER or $LOGNAME is going to work. I now have only these lines in rc.local:
The file useris.log looks like this:Code:echo The user is $USER > /var/log/useris.log echo The logname is $LOGNAME >> /var/log/useris.log exit 0
When I put those lines in their own bash script and run it from the terminal, I getCode:The user is The logname is
I wonder where we could find at which point in the boot process environment variables are set. It seems obvious that those two are set after rc.local runs.Code:The user is arist The logname is arist
Odd, isn't it, that an operating system designed explicitly for administration of multiple users doesn't have an easy way to restrict Internet access for selected users.
- Top
- Bottom
Comment
-
Re: Block URLs in browser?
mmm... now you've given me a serious problem!
Time to do some experimentation instead of just theory..."A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
- Top
- Bottom
Comment
-
Re: Block URLs in browser?
How To Set Up A Debian Linux Firewall
So why use a Linux system as a firewall if these $100 boxes are available? One reason is flexibility. You could use your Linux firewall system to simultaneously act as a Web (possibly with a Web cam) and/or e-mail server (more about this can be found on the Internet Servers and Web Cam pages). Plus you can set up very fine controls about who can access what on the Internet. Many organizations only want a few select individuals to have Internet access. In this case you could statically assign them addresses in a range outside of the DHCP scope and only allow that address range out. (If you have your own internal DNS server be sure to allow it outbound UDP port 53 so it can access the root hints servers.) But the main reason for setting up a Linux firewall is because it will help you learn Linux.Windows no longer obstruct my view.
Using Kubuntu Linux since March 23, 2007.
"It is a capital mistake to theorize before one has data." - Sherlock Holmes
- Top
- Bottom
Comment
-
Re: Block URLs in browser?
The problem is getting a user, AS A USER, to copy scripts owned by root.
In looking at a fall back position (/etc/profile or /etc/bashrc) I was unaware that
It seems that the favored way to run scripts as a user on Kubuntu is to use /etc/bash.bashrc, which should know what $USER or $LOGNAME are, to call11.6 It looks as if Debian does not use rc.local to customize the boot process ...
/bin/iftest.sh
from. And, you can use the user ID in a test:
iftest.sh
The single quotes are back-ticks (under the tilde sign). The "You should be "1000" (root is 0, other users range upward from 1000). You will still need to modify sudousers with visudo as mentioned before so that for running iftest.sh a password doesn't need to be entered.Code:#1/bin/bash if [ "`id -u`" -eq 1000 ]; then sudo cp stuff else sudo cp stuff if
If something like that doesn't work then perhaps you can try what Snowhog suggests and create an IPTABLES rule which passes all websites to you but excludes the targeted website from your other user. Never done that myself.
This is an interesting site: https://help.ubuntu.com/community/EnvironmentVariables
"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
- Top
- Bottom
Comment
-
Block URLs in browser?
Brilliant! That's the solution. I knew there had to be the right config file somewhere. Thanks, GG!
I just put "sudo /bin/blockurl.sh" into /etc/bash.bashrc, where blockurl.sh looks like this:
I have sudoers set to allow arist and nonarist to execute blockurl.sh without a password.Code:#!/bin/bash if [ "$USER" = "arist" ] then cp /etc/hosts.noblock /etc/hosts else cp /etc/hosts.block /etc/hosts fi exit
I can switch users to nonarist and the blocking takes effect. Unfortunately, when I log out of that account and am back in arist, the blocking is still in place. I suppose I'll have to log out each time instead of just switching users.
I will learn about firewalls when I have more time: looks like it should be an elegant and versatile solution. I've learned enough for the time being.
- Top
- Bottom
Comment
-
Re: Block URLs in browser? [SOLVED]
Nice solution - I usually just edit my hosts file directly. I wonder - could this be done using a local hosts file for each user hidden in the home directory?
Then you could add the file to skel and it would default into each new users setup but an admin could vary access to things by editing the individual files.
In other words, rather than using /etc/hosts.block use ~/.hosts and make the file read only and use /etc/hosts.base as your universal hosts. Then use the script to build a "new" /etc/hosts file by combining the /etc/hosts.base with ~/.hosts amended to the end.
This would remove the need for the if statement as you would do it every time. Any user needing full access could have a blank ~/.hosts . Just a different way to skin the cat I suppose.
While we're on the topic - there are several sites that have host files for free download that block various types of nefarious web sites. A quick web search will reveal many of them. I think it's a good idea to at a minimum block known malware site and I also block ad sites.
- Top
- Bottom
Comment
-
Re: Block URLs in browser? [SOLVED]
Are you switching to nonarist from within your KDE4 desktop, or do you log out and from the login screen log into nonarist?Originally posted by arist.....
I can switch users to nonarist and the blocking takes effect. Unfortunately, when I log out of that account and am back in arist, the blocking is still in place. I suppose I'll have to log out each time instead of just switching users.
...
To solve that problem the most likely place to put a call to your script is in YOUR ~/.bashrc file. Nonarist doesn't need any other changes.
#
~/.bashrc - Because of the way Ubuntu currently sets up the various script files by default, this may be the easiest place to set variables in. The default configuration nearly guarantees that this file will be executed in each and every invocation of bash as well as while logging in to the graphical environment. However, performance-wise this may not be the best thing to do since it will cause values to be unnecessarily set many times.
"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.
- Top
- Bottom
Comment
-
Re: Block URLs in browser? [SOLVED]
Much better. The problem wasn't completely solved after all: the system required a reboot to make the change in /etc/hosts. Using the local .bashrc appears to make it possible to change by just logging out and in.Originally posted by GreyGeekTo solve that problem the most likely place to put a call to your script is in YOUR ~/.bashrc file. Nonarist doesn't need any other changes.
So, the solution:
1. Copy the original /etc/hosts to /etc/hosts.noblock
2. Add unwanted web sites to etc/hosts and save as /etc/hosts.block. The additions look like this:3. Create two scripts, /bin/block.sh and /bin/noblock.sh. The first isCode:127.0.0.1 unwantedsite.com
The second is the same, but substituting hosts.noblock for hosts.block.Code:#!/bin/bash sudo cp /etc/hosts.block /etc/hosts
4. Edit the sudoers file to allow arist to run /bin/noblock.sh without a password, and the same for nonarist and block.sh
5. In arist's ~/.bashrc put the commandand do the equivalent (with block.sh) for nonarist.Code:sudo /bin/noblock.sh
Looks roundabout, but making system changes as root that affect selected users is tricky.
Anyway, thanks again to GreyGeek for the education. Now it's back to my real job for a few days, then off to iptables school.
Edit: The web restrictions can be easily got around by the user, since he/she owns ~/.bashrc and can just comment out the added line. That's not a concern of mine, but this solution won't work if the restricted users have decent Linux skills.
- Top
- Bottom
Comment
Users Viewing This Topic
Collapse
There are 0 users viewing this topic.







Comment