Securing this beast should serve as a nice training course for any sysadmin; bonus points if you start handing out shell accounts to anonymous people in certain neighborhoods of EFNet.
If this is based on a popular distro, maybe; but if you wanted to loosen up a Linux box, you can build a freak from pieces that no one would find lineage for, much less a repo.
Why sit around replacing packages by hand when you're not really learning anything? The best fix for a system like this is to nuke it from orbit and reinstall. I mean, odds are, you'll miss something, and then spent hours fooling around after getting hacked, when you could have just spent your time concentrating on what's important: saving relevant data and configuration, reinstalling, and securing the updated configuration.
The important point, which I did miss, is that it's not just a "security course", it's a course about how to break into things, so you need vulnerable programs. If you're not specializing in security stuff, the best course of action, is, however, to just keep your stuff up to date via apt or some similar mechanism.
But in order to properly understand what you could be vulnerable to and the why/how, you should learn how to break into things. Yes, normally, you're working at a higher level of abstraction, but if you want to understand how things really work, you work at a lower level for a while.
Riiight, downloading individual packages, libraries and kernels and building them from source. Which is why I thought it would be a good exercise, however very boring.
Running a Bastille script on the box would give you a quick TODO list. Pushing it to "production" and getting a few servers up and running, across version incompatibilities, would prove a bit more interesting. Running it under an older 2.4.x or 2.2.x kernel, doubly so.
I have spent hundreds if not thousands of hours upgrading random packages in Linux for various reasons. Afterwards, I didn't feel any wiser in security or anything except how to build stuff (well, maybe a bit of systems stuff...).
If upgrading is main task here, what do you really learn? If upgrading isn't the main task here, what is?
You can't be bug compatible for things that violate the processor's protection protocol. Access to certain bits of the EFLAGS register is unavailable to unprivileged code. In fact. Just because you were allowed to raid and pillage by Microsoft for a few years doesn't mean it's the norm.
You cannot meaningfully virtualize access to EFLAGS:IF. You can either emulate(/JIT) almost whole CPU or ignore this issue. And anyway, turning of interrupts is something that essentially does not make sense for user process, so it is better to just disallow that (which is what almost everything else but non-NT windows does)
It was usually used as an ultra- critical section. It would have been fine to simulate it as a scheduler-freeze for that process, preserving the meaning without getting hung up on the hardware implementation.
But instead, Intel decided to try to support actually messing with the interrupt enable state, resulting in years of highly-inefficient "solutions" e.g. trapping and simulating. Sigh.
A big-hammer approach is to set thread affinity for your process to one hyperthread/processor. But that loses the opportunity for lovely parallelism.
A finer-grained approach is to have a flag bit that prevents preemption, perhaps even just preemption by threads of the same process. This is weaker than CLI because it doesn't prevent I/O callbacks etc from preempting; ideally those would be suspended as well for the process.
This assume a non-priviledge flag word i.e. user-mode code owns the "process flags", not the kernel.
My favorite solution is a "process signal register" in hardware. Its a wide register full of test-and-set bits, shared by threads of a process. They can be used to implement critical section, semaphore, event, even waiting on a timer. All without a trip thru the kernel - essentially zero-latency kernel primitives.
Wouldn't an unprivileged EFLAGS-lookalike cause problems of the CLI-HLT persuasion?
And "process signal registers", while sounding attractive, aren't really a feasible alternative, given that the number of processes running even on uniprocessors are overwhelming, at least. Plus, if they're beyond CPU control, privilege issues arise again.
In short, yes, there are many alternatives, but the current model works, and not just for x86. And you know what engineers say..
I would say that not writing code that requires this. Only valid reason for wrapping something in CLI/STI is when you want to directly control some timing-critical hardware, which is something that simply does not belong into userspace. I would say that in most cases such code does not even belong to kernel, but into some interface controller of said hardware. Other cases are pretty well handled by normal APIs presented by kernel (mutexes, signal flags...).
Seems a decent educational tool too.. run in a virtual box and let your students go all out overflowing buffers and seeing the concepts in action. It comes with easy-to-follow guides.
OK for learning about what has been solved; kind of hacking-101. BUt the exploits involved have all been fixed in the products in that distro. What to use for the advanced class?
