Operating systems

I don't have a Windows-domain at home, so the Internet time client (NTP) is on relaxed settings. Your typical Microsoft documentation about NTP will have phrases like: "The default value for domain members is 10. The default value for stand-alone clients and servers is 15" in it. So, it really makes a difference if the computer is in a domain or not.

It is a well established fact, that the hardware clock on your computer is quite inaccurate. On a modern computer, there is no point in using expensive hardware to make the clock run smoothly, you can always set the time from a reliable clock source from Internet. That's what the NTP was made decades ago, to make sure that everybody has the same time in their boxes.

The real question here is: Why does my Windows 7 clock skew so much? I have set up the internet time, but it still is inaccurate.

As a Linux-guy I love doing my stuff on the command-line. To question about the clock skew I'll do:

w32tm /monitor /computers:-the-NTP-server-

... and it will respond something like NTP: -0.7900288s offset from local clock. So it's almost a second behind the accurate time source.

The initial fix is easy, force it to get the accurate time from the configured time server:

w32tm /resync

But I cannot be doing that all the time. Why cannot the computer maintain a well disciplined clock like I configured it to do? There must be something fishy about that.

A command like:

w32tm /query /status

will say that Poll Interval: 10 (1024s), but I cannot confirm that requests for every 1024 seconds (or less). It simply does not do that. There is a TechNet article with the title of Windows Time Service Tools and Settings describing a registry setting of MaxPollInterval located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config, but that has no real relevance here. The update mechanism does not obey that setting.

However, Microsoft's knowledge base article 884776 titled How to configure the Windows Time service against a large time offset gives more insight about the update interval. It describes a registry value of SpecialPollInterval located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient for manual peers. I'm guessing I have a manual peer, whatever that means. I don't have a domain and I did set the server manually. The original value seems to be 604800 seconds, making that 7 days or a week. Whoa! Way too much for me.

While sniffing the network traffic with the Wireshark, indeed I can confirm that putting a small value into that will make my Windows 7 to poll on that interval. I put 10 seconds there, and it seems to work. For any real life scenario 10 seconds to update time is ridiculous. For a computer on a domain, the value is 3600 seconds, making the updates for every hour. I chose to use that.

Please note that changing the registry value requires a restart for the Windows time client. From a command line a:

net stop w32time
net start w32time

will do the trick and start using the newly set registry value. You can also restart the Windows Time service from GUI.

Now my computer's time seems to stick with a reasonable accuracy. I'm still considering of purchasing a GPS-time box of my own. They seem to be quite expensive, though.

Most people don't much care about their Linux-boxes' security. You install it, you run it, you use it and occasionally run some system updates into it. Not me. When I have a box running against the wild wild Net, I absolutely positively plan to make the life of anybody cracking into one of my boxes as difficult as possible (with some usability left for myself). See Mr. Tan's article about Security-Functionality-Usability Trade-Off.

So, my choice is at the Functionality - Security -axis with less on the Ease-of-use. The rationale is that, a web application needs to run as safely as possible and can have the ease-of-use in it. The system administrator is a trained professional, he doesn't need the easy-part so much. However, there is a point, when things are set up too tight:

Image courtesy of Dilbert by Scott Adams

So, I voluntarily run software designed and implemented by NSA, SElinux. I even run it in the the Enforcing-mode which any even remotely normal system administrator thinks as being totally insane! Any small or even a tiny slip-up from the set security policy will render things completely useless. Mordac steps in and stuff simply does not work anymore.

On my Fedora-box there was a bug in BIND, the name server and an update was released to fix that. After running the update, the DNS was gone. As in, it didn't function, it didn't respond to any requests and the service didn't start. All it said was:

# systemctl status named-chroot.service --full
named-chroot.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled)
   Active: failed (Result: timeout)

Any attempt to start the service resulted in a 60 second wait and a failure. dmesg-log had nothing about the issue, nor BIND's own log had nothing about the issue in it. So I started suspecting a SElinux-permission issue. My standard SElinux debugging always starts with a:

cat /var/log/audit/audit.log | audit2allow -m local

... to see if SElinux's audit logger is logging any permission-related audit faults. Indeed it did:

require {
        type named_conf_t;
        type named_t;
        class dir write;
}

#============= named_t ==============
allow named_t named_conf_t:dir write;

That reads:
A process running in named_t security context is trying to access a directory with named_conf_t security context to gain a write access, but is denied while doing so.
It is obvious that the process in question must be the BIND name server. No other process has the named_t security context in it. When starting up, BIND name server was about to write into its own configuration directory, which is a big no no! When you write, you write only to designated directories, nowhere else (remember: running in enforcing-mode is insanity).

That is definitely a reason for a daemon not to start or to timeout while starting. Further investigation showed that also Fedora's SElinux policy had been updated a week ago: selinux-policy-3.12.1-74.19.fc19.

At this point I had all the pieces for the puzzle, it was simply a matter of putting it all together. The recently released SElinux policy has a bug in it, and nobody else was there to fix it for me.

The exact audit-log line is:

type=AVC msg=audit(1395481575.712:15239): avc:
denied  { write } for
pid=4046 comm="named" name="named" dev="tmpfs" ino=14899
scontext=system_u:system_r:named_t:s0
tcontext=system_u:object_r:named_conf_t:s0 tclass=dir

So, my chrooted BIND-damon was trying to write into a tmpfs. There aren't that many of those in a system. I've even touched the tmpfs-subject earlier when I wrote a systemd-configuration into my own daemon. To find the tmpfs-usage, I ran:

# mount | fgrep tmpfs
tmpfs on /var/named/chroot/run/named type tmpfs

BIND's chroot-environment has one. That is very likely the culprit. That can be confirmed:

# ls -Z /var/named/chroot/run/
drwxrwx---. named named system_u:object_r:named_conf_t:s0 named

Yep! That's it. The directory has incorrect security context in it. To compare into system's non-chrooted one:

# ls -Zd /run/
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run/

There is a difference between named_conf_t and var_run_t. You can write temporary files into latter, but not to the first one. The fix is very simple (assuming, that you speak fluent SElinux):

semanage fcontext -a -t var_run_t "/var/named/chroot/run(/.*)?"
restorecon -R -v named/

The two commands are:
First, re-declare a better security-context for the directory in question and then start using the new definition. Now my BIND started and was fully operational! Nice.

My investigation ran further. I needed to report this to Fedora-people. I looked into the policy-file of /etc/selinux/targeted/contexts/files/file_contexts and found the faulty line in it:

/var/named/chroot/var/run/named.*       system_u:object_r:named_var_run_t:s0

That line almost works. The directory in question has only two files in it. One of them even has a matching name. The problem, obviously, is that the another one does not:

# ls -l /var/named/chroot/run/named/
total 8
-rw-r--r--. 1 named named   5 Mar 22 12:02 named.pid
-rw-------. 1 named named 102 Mar 22 12:02 session.key

See Bug 1079636 at Red Hat Bugzilla for further developments with this issue.

One day my laptop shut itself down while I was getting a cup of coffee. No big deal, I thought. I'll just plug it into charger and things will be ok again. It took me by surprise to see, that the battery was 80% charged and the laptop had done a "crash landing". Apparently it chose to turn itself off. I'm guessing to avoid an over-heating situation.

Couple of weeks later I realized that a machine that does not do anything, chews about 25% CPU constantly. The natural guess would be a virus scanner, but it turned out to be a process called IEWebSiteLogon.exe:

I've never heard of such an application. Google didn't reveal anything useful, but the process properties revealed that the file was located at C:\Program Files\Lenovo Fingerprint Reader\x86\, so the conclusion is that my fingerprint reader's software is running a piece of software to eat up a lot of CPU-resources to do exactly nothing.

The file name gave me a hint, that it has something to do with Internet Explorer. I was running IE 11:

I opened the add ons manager:

and there it was. My initial idea of disabling the stupid thing didn't pan out. The Disable-button is grayed out. Searching The Net revealed two interesting pieces of information: How to Remove Unneeded Plug-Ins in Internet Explorer By Andy Rathbone from Windows 8 For Dummies, which proved to be useless, it instructs to disable the add on. The second yielded results: Can't remove Internet Explorer Add-On. It described a way to track down the component by its class ID. Nice, but not nice enough. Somewhere there is a piece of code to attempt to load the missing component. Why not remove the requirement?

The details of the add on are:

Now I had the class ID of {8590886E-EC8C-43C1-A32C-E4C2B0B6395B}. According to SystemLookup.com is a valid piece of software, they say: "This entry is classified as legitimate". That class ID can be found in my Windows system's registry from the following locations:

• HKEY_CLASSES_ROOT\CLSID\
• HKEY_CLASSES_ROOT\Wow6432Node\CLSID\
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\
• HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Approved Extensions
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\

The interesting ones are the system setting of Browser Helper Objects and user setting of Approved Extensions. Removing the helper object surely will disable the add on completely. Also it will be a good idea to make it a not-approved extension. And to un-register the component. All that should give the stupid add on a decisive blow and make it not waste my precious CPU-cycles.

The following PowerShell-commands run with administrator permissions will do the trick:

Remove-Item -path
  "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"
Remove-Item -path
  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"
Remove-ItemProperty -path
  "HKCU:\Software\Microsoft\Internet Explorer\Approved Extensions" -name "{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"

If you don't have admin-permissions, the commands will fail. Also please note that every time Internet Explorer is started, it will make sure that permissions in the registry HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Approved Extensions are set so, that user is denied any modification access. See this:

I tried to remove the deny ACL with PowerShell, but it seems to be impossible. The API is not mature enough.

After removing the deny ACL and running the PowerShell-commands and finally stopping and starting the Internet Explorer, the add on was gone. I managed to "disable" it completely.