I previously talked about wrapping glibc functions and the possibility of doing a mandatory control system out of it. Well, the short version is, it doesn’t work right on multi-arch systems, which is pretty much a deal breaker for me. So unless you want this error spat out on every single command that is ran:
ERROR: ld.so: object '/usr/lib/glguard.so' from /etc/ld.so.preload
cannot be preloaded: ignored.
Then you’re SOL. Oh well, it was worth a try. On to other things!
Early this morning I got a bug report from someone that, when the full path to a file is sufficiently long enough, a denied execution of it will throw a NULL pointer exception in the kernel. This evening I researched the issue and coded in a fix. Basically, the error reporting tried to print out a NULL pointer under those conditions. How embarrassing for me to not notice this.
If you’re using the tpe-lkm module, you’ll want to update it. I’ve also bumped the version number.
Many thanks to Panos Sakkos for the bug report!
The other day I came across an old forum post about logging exec calls to syslog without modifying code anywhere. I was intrigued; I didn’t know you could hook into glibc function calls like this. I wonder how far can this go? Naturally, I decided to take a quick whack at it myself, and I ended up coding a very basic implementation of Trusted Path Execution with it. I got good (although puzzling) results:
I used to maintain a grsecurity kernel rpm repository, but haven’t kept it online due to lack of proper build infrastructure. The servers, the code, the effort in keeping everything working order – I admire what the CentOS guys have put together, and look forward to the possibility of them releasing their reimzul for everyone to use. Maybe one day I’ll do the repository thing again.
Anyway, I get asked occasionally about the rpms, if I still make them, and how they were made. So, in the absence of me pre-building the RPM files, here is my kernel-grsec rpm spec file that I used to build them. Hope you find it useful.
About a year ago, I posted about me coding a TPE module for distribution kernels. In that time I’ve added some features, fixed some bugs, and deployed it to all of my non-grsecurity systems. With the last known outstanding bug (that I know about) being fixed a little over two weeks ago (and tested) I’m excited to say that, you guessed it, tpe-lkm is ready for wider deployment.
Imagine making someone’s computer only play the Rick Astley song “Never Gonna Give You Up”, no matter what mp3 file they tried to play, no matter which media player they tried to play it with. Wouldn’t that be neat? (or annoying?)
Well, now you can. At least, with certain versions of the linux kernel, that is.
Have you ever had an RPM installed on the system that you needed installed on another system, but didn’t have the .rpm file for it? Or, have you wanted to make a .rpm file with just a minor change without having to completely rebuilt it? Or perhaps forge an RPM with some naughty scripts or binaries in it?
Check out my rpm-repack script. Simply run it with the package name that’s installed on the system:
Having to manage a wide array of servers with vastly different disk configurations, I found that things began to be very tedious with the nagios configuration file for disks checks. It seemed as if no two server disk configuration was the same, and coming up with a scheme to have different partitions be a consistent index number across systems was proving to be difficult.
It’s about time I post a detailed explanation about how my tpe-lkm module is able to enforce its security policy. This post is very technical, readers beware. Note that this writeup is based on the code as it was the latest commit, which was of this writing, was the one on Dec 10th, 2011. I’ll keep all the links relative to that date.
The other day I threw together a check_snmp_time.pl script that simply checks the remote’s time against the monitor host’s time. It’s fairly straight forward, and will alert you when host’s time drift too much, indicating that your ntpd configuration is bad. I had to do some custimizations to it, because not all hosts have the HOST-RESOURCES-MIB::hrSystemDate.0 option. For hosts that don’t it falls-back to the UCD-SNMP-MIB::versionCDate.0 option.