This evening I wrote a chunk of code that, given a PID, goes and does the chdir() and chroot() calls on it to a given directory. That process suddenly finds itself isolated while it’s running. It’s kind of like pulling the carpet pulled out from under it, but so quickly it doesn’t notice.
In other words, I’m kidnapping a process, and stuffing it into a chroot.
Since I already had my hands in the tpe-lkm code yesterday, I decided to spend my lunch break coding a feature I’ve been meaning to add in for a while now.
I added a new ps extras feature. Since it doesn’t have to do with the “trusted path”, I added it to the “extras” in the configuration. It’s similar to grsecurity’s “Proc restrictions” where “the permissions of the /proc filesystem will be altered to enhance system security and privacy”. Basically, non-root users won’t be able to view the processes they don’t own.
I have committed a fix to the tpe-lkm project that fixes a DoS condition I previously noted.
It also introduces a new sysctl entry, log_max, as to prevent logs from getting filled up horizontally. I set the default to 50, seemed high enough without giving an attacker too much leverage on spewing junk into the log file should they get the chance, yet low enough to catch the full process tree of you basic exploit attempt.
I’ve discovered my first denial-of-service bug in the linux kernel. I’m a bit teary eyed, not because the bug was in my own code, but it marks the first bug I’ve found in linux kernel code.
Not worth of a CVE or anything, because I still haven’t declared the code stable, and I don’t imagine many people use this thing just yet. But in the interest of full disclosure, here is information about the bug.
I’ve noticed that I have started to put on some weight (again). The last time my weight started to go up, I counted calories, and managed to get the weight down and stable for a little over a year. This time, however, I’m going to do something different about it.
In the spirit of the various “Occupy” protests lately, I’ve decided to start my own private protest:
Occupy Kitchen
Since I’m on a nagios and snmp kick this week, here’s a nagios snmp plugin I wrote to check memory and swap. The real difference between this script and the standard nagios plugins for memory / swap, is it takes buffered and cached memory into account, giving the real % free.
Here is the check_snmp_memory.pl script, and it’s usage is pretty simple:
So there is a currently unresolved issue with the check_snmp nagios plugin where it doesn’t use the snmp.conf file. I use v3 of the protocol, and don’t want to have to put the big long string everywhere in the nagios configuration file:
define command{
command_name check_snmp_cpu
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -w 2 -c 4 -u "cpu" -P 3 -L authPriv -a MD5 -U snmpmonitor -A "have a look at what I have to offer" -x des -X "have a look at what I have to offer" -o .1.3.6.1.4.1.2021.11.10.0
}
So I came across little vps a while back, and finally placed an order last week. So far, I’m extremely impressed with their control panel’s functionality, especially their pv-grub option for running your own xen kernel. Their support takes a little while to respond, but for hosting at such a low price, what do you expect?
Bottom line up front; the GPL license is viral.
I have had a lot of discussions with people about software licensing, and it amazes me how few of them really understand them, especially the GPL. I’ll do a quick comparison of licenses:
EULA: sharing is evil BSD: sharing is not evil GPL: not sharing is evil
Disclaimer: I have no affiliation with ksplice, I’m just a guy who knows something about hot-patching the linux kernel and figured out how this ksplice thing works. I strongly agree with the sentiment that the ksplice raw utilities is not for general use. In fact, Ksplice says in the distribution of these tools:
Without the appropriate expertise and safety infrastructure, the raw utilities can create subtly incorrect rebootless updates, which can have serious consequences.