Glocker essentially does two things. One - It blocks certain domains, keywords and applications. Two - It gathers statistics about usage so that behaviour patterns can be identified and acted upon.
Let’s talk about blocking first.
Domains
This is in the domains: stanza. The enabled key turns this feature on. You’d probably want this on since it’s the most useful feature and what I originally built back in the day. The hosts_path points to the default hosts file on Linux machines so you probably don’t need to change it.
The list key is what contains the list of domains to block. Basic blocking can be done by just listing the domain under the list key. For example, if you want to block twitter.
list:
- name: "twitter.com"
it will be blocked and you cannot view it. There are some sites which you want to block most of the time but might want to unblock for short periods (e.g. YouTube if you need to watch a tutorial about something you need). You can configure this by setting an
list:
- name: "twitter.com"
unblockable: true
You can unblock such domains by issuing a glocker -unblock twitter.com:research command which will unblock twitter.com. The unblocking settings are inside the domains.unblocking stanza. There are a few settings inside here that we can cover. First of all the reasons key gives a list of reasons which are acceptable inputs to the -unblock command. If you’re honest with these, it’s recorded so that you know why you’re unblocking. There’s a log_file which you probably shouldn’t change. It’s where unblocks are recorded. When you unblock, the site will remain unblocked for temp_unblock_time minutes. And finally, there’s a cap on the number of times you can unblock which is specified in max_per_day. A typical unblocking section looks like
unblocking:
reasons: ["work", "research", "emergency", "entertainment", "education", "relax"]
log_file: "/var/log/glocker/unblocks.log"
temp_unblock_time: 20 # minutes a domain stays unblocked
max_per_day: 3 # max unblocks per calendar day (0 = unlimited)
Going back to the list of domains, you might want to block domains only during some times of the day. You specify that like so (e.g. block twitter.com from 9:00 to 17:00 and again from 21:00 to 2:00) during weekdays but relax the schedule on weekends.
- name: "twitter.com"
unblockable: false
block_windows:
# Blocked during work hours on weekdays
- start: "09:00"
end: "17:00"
days: ["Mon", "Tue", "Wed", "Thu", "Fri"]
# Also blocked in the evening (to encourage sleep)
- start: "21:00"
end: "2:00"
days: ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]
For large lists of domains, it supports an !include directive like so
list:
- !include conf.d/domains-social-media.yaml
Each of the files !included here are a list of domains. This is convenient when the list gets large. There is a helper program called update_domains.py which can be used to write out several large domain lists from public sources.
When you hit a blocked domain from any program (not just your browser), an alarm can be configured using the blocked_access_command. I set it to something like mpg123 /home/user/Downloads/alarm.mp3.
Sometimes, you end up visiting a site which you decide you want to stay off of. You can use the glocker -block to block it on an ad-hoc basis. This will block the domain but it will not survive a reinstall. We will come back to this later. However, for many programs (mostly browsers), resolved hostnames are cached. If you include a program inside the domains.kill_on_block list, glocker will kill them when you block a domain so that resolved domains will get cleared. It’s a little inconvenient but it’s effective.
Programs
One of the other problems I had was that I’d sit in the evening and end up playing casual games. This would affect my bedtime. Glocker can kill programs just like it blocks domains and the stanza that handles this is programs. Setting enabled to true will turn this on. The check_interval_seconds is how frequently it will check for the programs running. 5 is reasonable and it’s the default. Then there’s a list. An entry like
list:
- name: "brave"
will kill the Brave browser as soon as it’s seen. Just like the domains, you can specify time slots where the killing will happen. Here’s a more detailed example to make sure Brave can’t be run from 20:00 to 5:00 the next day.
- name: "brave"
kill_windows:
- start: "20:00"
end: "05:00"
days: ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]
Sometimes though, a program that you genuinely need (e.g. your primary browser - firefox) gets killed in a kill window but you still need it. If you mark a program with extendible:true, a one time one hour extension can be requested for it every 24 hours with glocker -extend firefox:work where you specify the reason for extension and the program similar to how we unblock domains using -unblock. And similar to the domains, there’s a -block-app command for glocker which will allow you to mark a program as not allowed. It will start killing it if it starts. And just like domains, this is not a persistent change. It will not survive a reinstall.
I add browsers which aren’t supported by Glocker and which bypass local DNS lookup (e.g. like Mullvad) to this so that they’re not allowed to run.
Content
Sometimes, you don’t want to block a site completely. But you want to block sites which have certain words in them. For example, you can block all sites that refer to “gambling” either in the URL or in the body. These are controlled in the content stanza. It also has an monitoring.enabled key similar to the others and a monitoring.log_file to record violations. Then we have the keywords sub stanza which has url_keywords and content_keywords keys that have lists of words which, if detected, will cause the site to get blocked. There are of course some sites which shouldn’t be blocked even if the string is there and these can be specified in the keywords.whitelist list. Wikipedia is an good example in my own whitelist.
This works only in supported browsers. I use Mozilla Firefox myself and one of the reasons why I ended up writing this program is because things like plucky didn’t support Firefox. An extension runs inside the browser. It’s a small add-on that periodically pulls the keyword lists from glocker and then watches the address bar and the text of every page you open. The moment it spots a blocked keyword, it reports the hit back to glocker and redirects the tab to a blocked page, so you never really get to see the content. glocker records that hit (in the monitoring.log_file above), and it also counts as a violation. The extension also prevents you from opening incognito windows and will apply to all FF browser profiles.
Chrome and Chromium are supported similarly. The installer sets up a browser policy that installs the extension automatically for all profiles, and it can’t be disabled or removed. Chrome doesn’t allow an extension to be forced into incognito windows, so glocker turns off incognito and guest windows completely. It also turns off “secure DNS” (and Brave’s Tor windows) since those skip the local DNS lookup that domain blocking relies on. Chrome, by design, checks glockerapp.com every few hours for updates to the extension so that it stays current.
I do want to highlight that my own browser is Firefox so it’s better tested than the Chrome family.
Sudo restriction
One of the problems with any of these things is that if you have root on the system, you will be able to bypass them thereby making the whole thing just an inconvenience rather than a restriction. glocker has a feature where it can lock you out of sudo for a period of time. When you’re locked out, you can interact with glocker only via. the command line (ie. glocker commands). Some of them are disabled (e.g. -uninstall) and the files which it uses to enforce blocking are not editable unless you have root. This is controlled with the sudoers stanza. It also has an enabled key to turn it on. It does its work by swapping out the allowed_sudoers_line with the blocked_sudoers_line outside of the allow_windows. Inside the window, allowed_sudoers_line will be in /etc/sudoers.d/glocker and outside the window, it will be blocked_sudoers_line. For this to hold, glocker has to be your only way to sudo. So on Debian, Ubuntu, Fedora, Omarchy and Arch, the install takes over your existing sudo access (it removes you from the sudo/wheel group or moves your own sudoers file aside) and -uninstall puts it back. On other distributions, the sudo window isn’t available. A line like
john ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/dmesg, /sbin/service docker *, /sbin/service networking *
will allow the user john to run only the apt, dmesg, service docker * commands and service networking * commands. To keep the whole thing open which the allowed_sudoers_line does, we set it to
john ALL=(ALL) NOPASSWD:ALL
While the mechanism is simple, this is the crux of the enforcement. If you don’t have unrestricted root, you simply cannot edit the hosts file, kill glocker or break out of the environment it puts you in. Without this, any measure that you implement will be circumventable.
A side effect of this is that you can only upgrade glocker, edit the config or do other things like that within your sudo window. I generally give myself sudo within my working hours since I might need to twiddle with my laptop but over time, I’ve figured out which are the main commands I needed (apt, dmesg etc.) and just given myself rights to run those as root.