[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 20/08/13 21:17, Simon Waters wrote: > I sometimes still work on console, admittedly this is usually X is broke, or I'm > doing something which will break X, or just might break X. Me too, but usually in a server room because hard access is required (usually physical work is taking place on a system which is why I'm in the server room instead of remote). Also on workstations when I've taken down X to upgrade the official Nvidia drivers or what-not. In any case, with the possible exception of an access-controlled server room, I'd *never* walk away from an unprotected console in any environment where I wasn't with 100% trusted friends/colleagues in the first place. That's just common sense. > I think vlock aims to address this issue. Wow, I didn't know this program either - thanks! It does exactly what you'd imagine, very handy. > Physical access to system console is pretty hard to secure fully as there are a > few tricks, for example SysRq, which will defeat naive attempts (assuming the > power button is not to hand). This is a myth, really. SysRq shouldn't be casually left alone - a sysadmin should know whether their kernels have been built with CONFIG_MAGIC_SYSRQ or not and it, and I lock down non-root access to the /proc/sysrq trigger interface with SELinux. Secure your bootloader and firmware with passwords (EFI, BIOS, OpenBoot, etc) to avoid tampering at boot time like entering arbitrary commands into an EFI prompt, reconfiguring BIOS boot order and resetting passwords. Locked down Grub on Linux boxes prevents smart-arses booting either the rescue mode and escalating trivially to root or modifying boot stanzas otherwise (passing fake init=/bin/evil) Full disk encryption is obvious - even if they can find the power button or reseat the power lead, it's only going to trigger an alert to me and present them with an inescapable and unalterable boot sequence, taking them straight back to either a FDE prompt or a standard login prompt. Important boxes you care about are either in the secure server room, in the case of end-user boxes, secured with Kensington securelock cables or similar so they can't be opened or removed to fiddle about with CMOS reset jumpers or taking out the BIOS batteries to drain them and trigger a default reset. That's not 100% secure, but it's almost unbeatable against anything but internal agents with a lot of time and patience to mount attacks and government agents with guns (nothing is secure against them!). > See also "Inception" and the trouble an interface that allows DMA can cause. But > Inceptions authors assume disk encryption as otherwise reboot and you are root. Now, I happen to be pretty familiar with Inception, and it's not all it's cracked up to be... by a long shot. It had a brief moment in the sun, but then everything patched it - if you actually try it against the list of targets they're currently claiming work, you'll find in real life the vast majority don't. You not only need physical access, but both your cracking laptop and most importantly, the target box, need to have firewire ports (they claim any PCI/PCIe style extension DMA-capable interface like Thunderbolt or ExpressCard is by extension vulnerable, and then list a ridiculous amount of caveats - you still need to connect a firewire cable no matter what, which means making your own manual patch interfaces and installing them on the targetted device, then rebooting it and letting it install drivers, etc, etc... trust me, this doesn't work, I've tried it) and good luck with that. Virtually nothing has firewire ports on it these days - some Macs still have them for legacy, all older Macs have them by default (but are on old OS versions and are vulnerable anyway, plus they don't have full disk encryption beyond FileVault which is also vulnerable in old versions) and I don't think I've ever seen a server with a firewire port, ever. Even the handful of consumer Intel machines I've seen that even have firewire ports, half of the time there's not actually a header for them on the mobo anyway so they're just dummies. And on top of that, note only basic windows, linux and os x for consumer level stuff is targetted: Solaris, AIX, enterprise Linux (CentOS, RedHat, SUSE, Oracle) Windows Server, BSD are all missing. Any 64bit OS that sensibly keeps the sensitive paging areas out of the lower 4Gb of RAM actually addressable by DMA immediately foils this (Linux does this by default, I'd personally be surprised if the listed vulnerable Ubuntu/Mint distros in 64bit mode are actually still vulnerable - I'd think not). Inception's DMA read is actually flakier than that - it will frequently barf after accessing only the first 2Gb. In addition, pretty much all free Windows AV toolkits also know of Inception/DMA attacks and have been blocking endpoints ever since. So even windows isn't vulnerable if you just install AVG for example. Lastly, Mac OS, which was originally the most vulnerable - because it generated the best headlines at the time - has also long since patched this too: if you enter a EFI firmware password on your Mac (see above) DMA is disabled, as well as if you enable FileVault. Plus Mac OS has endpoint blocking AV these days too. TLDR: Inception isn't a big deal at all. Particularly if you're not running a prehistoric Mac with no DMA protection whatsoever, it's a non-issue. No thunderbolt/firewire on your workstation? 100% immune. > > Something like bash TMOUT might help, but if security really matters you probably > want to take more extreme measures. One place I worked you locked the hard drives > away in a safe when you left your machine, well for a certain group of users. Of > course you still check the machine for tampering before reinserting, but it avoids > the data disappearing overnight. My SGIs all have removable drive sleds - you just open a lockable drive door on the front (they can have an additional solid metal 'locking bar' threaded through the entire solid steel case as well for extra security), flip the catches and slide out the spring loaded trays, which look absolutely awesome by the way: http://www.sgidepot.co.uk/sgidepot/pics/onyxdisksled.jpg This is because the first SGI contracts were for American three-letter-agencies, and all boxes from then on were specced with full military clearance in mind. In those environments, all workstations were powered down, disk sleds removed and locked up in a safe by an armed quartermaster every day at close of business! Now *that's* how you handle physical security*. Regards *You'll still have to look out for employing people called "Snowden" though... -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq