I have now got a Debian Xen domU running the strict SE Linux policy that can boot in enforcing mode. I expect that tomorrow I will have it working with full functionality and that I will be able to run another SE Linux Play Machine in the near future.
For more information on my work on security features in Debian read the full version of this post on my new blog.
E-Week has an article about the popular computer hardware review site Tom's Hardware (tomshardware.com) being hit by a trojan in a banner advert.
From the article it's not clear whether a criminal paid for a banner advert under a legitimate business name or compromised the advertising server run by an innocent third-party who paid for advertising on Tom's Hardware.
But really it doesn't matter very much for users. The facts that are clear are that Tom's Hardware is a very reputable site (that I personally visit regularly and recommend highly) that apparently did nothing wrong. Yet Windows users who visited the site who hadn't applied the latest patches had their systems compromised (and presumably used for other criminal activity). Apparently a month ago there was a patch released for the bug in question.
One thing that has to be noted is that large corporations often don't apply patches immediately. Spending a month testing a patch before deploying it widely is not uncommon in an enterprise environment. The general thinking in an enterprise is that the employees are almost always prohibited from visiting porn sites, and often prohibited from using forums, and webmail services. With these things prohibited the risk of attack is dramatically reduced. Now there is evidence that even the most reputable sites run by the competent sys-admins can be vulnerable to such attack.
The rest of this post is on my new blog.
Frank Mayer of Tresys has written a great article on the techtarget.com site about SE Linux.
It seems mostly aimed at managers and novice users and explains how SE Linux isn't really that difficult to use but is however a foundation technology that is needed for secure systems.
Check it out!
Sune Vuorela asks about how to secure important data such as GPG keys on laptops.
I believe that the ideal solution involves booting from a USB device with an encrypted root filesystem to make subversion of the machine more difficult (note that physically subverting the machine is still possible - EG through monitoring the keyboard hardware).
The idea is that you boot from the USB device which contains the kernel, initrd, and the decryption key for the root filesystem. The advantage of having the key on a USB device is that it can be longer and more random than anything you might memorise.
In my previous posts about a good security design for an office, more about securing an office, and biometrics and passwords I covered some of the details of this.
My latest idea however is to have the root filesystem encrypted with both a password that is entered and by a password stored on the USB device. This means that someone who steals both my laptop and my USB key will still have some difficulty in getting at my data, but also someone who steals just the laptop will find that it is encrypted with a key that can not be brute-forced with any hardware that doesn't involve quantum-computing.
Also coincidentally also on Planet Debian in the same day Michael Prokop documents how to solve some of the problems relating to booting from a USB flash device.
I posted the NSA paper titled The Inevitability of Failure on my source-dump blog at this URL. If you want to get the background to SE Linux then this is the paper to read.
Submitting big documents (62K) to Blogger turns out to be surprisingly painful. It's a pity that Blogger doesn't support editing sections (as MediaWiki does) so every edit requires that the entire document be transferred back and forth. Do other blog servers make this easier?
I just received a question about SE Linux via email. As I don't want to post private messages containing material that's globally useful I'll answer through my blog:
> other than strict and targeted policies......other policies like
> RBAC, MCS, Type Enforcement are also there....how are these policies
> implemented
The two main policies are the strict policy and the targeted policy. The strict policy is the earliest and was originally known as the sample policy (but was given the name "strict" after targeted was developed).
The strict policy aims to give minimal privileges to all daemons. The targeted policy aims to restrict the programs that are most vulnerable (network facing daemons) and not restrict other programs (for ease of use). There is currently work in progress on combining those policies so the person who compiles the policy can determine which features of strict they desire.
RBAC means Role Based Access Control. The strict policy assigns users to roles and the role then limits the set of domains that can be entered. For example the user_r role does not permit the sysadm_t domain so a user who is only permitted to enter the user_r role can not perform sys-admin tasks. Like many terms RBAC is used in different manners, some people consider that it means direct control by role (EG role user_r can not write to /dev/hda), while SE Linux has a more indirect use of roles (role user_r can not run programs in domain sysadm_t or any other domain that allows writing to type fixed_disk_device_t - the type for /dev/hda). You may consider that the strict policy supports RBAC depending on which definition of the term you use.
Generally the targeted policy is not considered to support RBAC, although if you consider a role to merely be a container for a set of accesses that are permitted then a SE Linux domain could be considered a in the RBAC sense. I don't think of targeted policy as being a RBAC implementation because all user sessions run in the domain unconfined_t which has no restriction. I think that to be considered RBAC a system must confine user logins.
Type enforcement is the primary access control mechanism for SE Linux. Every object that a process may access (including other processes) has a type assigned to it. The type of a process is known as a domain. The system has a policy database which for every combination of domain, type, and object class (which is one of dir, file, blk_file, etc - all the different types of object that a process may access) specifies whether the action is permitted or denied (default deny) and whether it is audited (default is to audit all denied operations and not audit permitted operations).
MCS is a confidentiality protection mechanism where each file has a set of categories assigned to it. The set may be empty, may contain all 1024 categories, or any sub-set. Each process has a set of categories that determines which files it may access. File access is granted if Unix permissions allow it, if the domain-type model allows it, and if MCS allows it (on an MCS system). I have just had an article on MCS published in Linux Journal.
MCS is an optional feature for people compiling Linux from source or for distribution vendors. For Red Hat Enterprise Linux, Fedora, and Debian the decision was made to include it, so the strict and targeted policies for those distributions include MCS.
There is another policy known as MLS. This is a policy build that comprises the strict policy plus Multi-Level Security. Multi-Level Security aims to give the highest confidentiality protection and comply with the LSPP (Labeled Security Protection Profile - roughly comparable to B1) Common Criteria certification. It would be possible to build a targeted policy with MLS but that wouldn't make sense - why have the highest protection of confidentiality with anything less than the highest protection of integrity?
As for how the policies are implemented, I'm not about to write a tutorial on policy writing for a blog post, I'm sure that someone will post a link to a Tresys or Fedora web page in the comments. ;)
> there r some packages of linux in which some changes has been made
> to support linux......for eg:- coreutils, findutils
That is correct. Every program that launches a process on behalf of a user at a different privilege user (EG /bin/login, sshd and crond) and every program that creates files for processes running in different domains (EG logrotate creating new log files for multiple daemons) needs to be modified to support SE Linux. Also ls and ps were modified to show SE Linux contexts as well as the obvious programs in coreutils.
> 'Z' is the new thing that have been added to most of the
> utilities......wherever I search I get the changes made only in few
> utilities like ps, mv, cp, ls
>
> Can u help me by giving all the changes made in each of the utilities.....
Unfortunately I can't. This has been identified as an issue and there is currently work in progress to determine the best way of managing this.
Debian is participating in the Google Summer Of Code (or Winter if you are in the southern hemisphere).
It would be good if we could get a SE Linux related project in. If you are interested in doing some SE Linux work (or other security related work) in this regard then please let me know. I'm interested in helping mentor for such projects.
One of the most obvious (and yet most common) computer security mistakes is to take input from an untrusted (and potentially hostile) source. A classic example of this is in Windows Vista where audio output from the system speakers can be taken as input to the speech recognition system. According to the BBC article an MS representative said "it would be unlikely the user would not be in the room to hear the file with malicious instructions being played".
It seems that according to MS it's OK for your computer security to be breached, just as long as you are around to witness it!
A post by Scott James Remnant describes how to hide command-line options from PS output. It's handy to know that but that post made one significant implication that I strongly disagree with. It said about command-line parameters "perhaps they contain sensitive information". If the parameters contain sensitive information then merely hiding them after the fact is not what you want to do as it exposes a race condition!
One option is for the process to receive it's sensitive data via a pipe (either piped from another process or from a named pipe that has restrictive permissions). Another option is to use SE Linux to control which processes may see the command-line options for the program in question.
In any case removing the data shortly after hostile parties have had a chance to see it is not the solution.
Apart from that it's a great post by Scott.
The issue of core file management has come up for discussion again in the SE Linux list.
I believe that there are two essential security requirements for managing core files, one is that the complete security context of the crashing process is stored (to the greatest possible extent), and the other is that processes with different security contexts be prevented from discovering that a process dumped core (when attacking a daemon it would be helpful to know when you made one of it's processes dump core).
The core file will have the same UID and GID as the process that crashed. It's impossible to maintain the complete security context of the crashing process in this manner as Unix permissions support multiple supplementary groups and Unix filesystems only support one GID. So the supplementary groups are lost.
There is also a sysctl kernel.core_pattern which specifies the name of the core file. This supports a number of modifiers, EG the value "core.%p.%u.%g" would give a file named "core.PID.UID.GID". It would be good to have a modification to the kernel code in question to allow the SE Linux context to be included in this (maybe %z).
To preserve the SE Linux context of the crashing process with current kernel code we need to have a unique type for each process that dumps core, this merely requires that each domain have an automatic transition rule for creating files in the directory chosen for core dumps. In the default configuration we have core files dumped in the current directory of the process. This may be /tmp or some other common location which allows an attacker to discover which process is dumping core (due to the directory being world readable) and in the case of SE Linux there may be multiple domains that are permitted to create files in /tmp with the same context which gets in the way of using such a common directory for core files.
The traditional Unix functionality is to have core files dumped in the current directory. Obviously we can't break this by default. But for systems where security is desired I believe that the correct thing to do is to use a directory such as /var/core for core files, this can be easily achieved by creating the directory as mode 1733 (so that any user can create core files but no-one but the sys-admin can read them) and then setting the core_pattern sysctl to specify that all core files go in that directory. The next improvement is to have a poly-instantiated directory for /var/core such that each login user has their own version. That way the user in question could see the core files created by their own processes while system core files and core files for other users would be in different directories. Poly-instantation is easier to implement for core files than it is for /tmp (and the other directories for which it is desirable) because there is much less access to such a directory. When things operate correctly core files are not generated, and users never need to access each other's core files directly (they are mode 0600 so this isn't possible anyway).
This area will require a moderate amount of coding before it works in the ideal manner. I aim to briefly describe the issues only in this post.
While reading the discussion of Vista security on Bruce Schneier's blog it occurred to me that comparing the issues of DRM that face MS with the issues faced by SE Linux developers provides some benefits.
SE Linux is designed to enable the owner of a computer to effectively enforce security policies to protect their system integrity and the confidentiality of their data. Some of the SE Linux users (military users) use all the available features, but most people only use the targeted policy which provides a sub-set of the system integrity and data confidentiality protections that are available to give a greater ease of use.
Fedora and Red Hat Enterprise Linux ship with the SE Linux targeted policy enabled by default. This policy is not something that most users notice. The main program that is commonly used which might have an issue with the default SE Linux policy is Apache. Fedora and RHEL systems that do not run Apache (which is most of them) can run SE Linux with almost no costs.
setsebool -P httpd_disable_trans 1It seems clear to me that there is no good reason for disabling SE Linux by default. There are reasons for running a particular daemon in the unconfined_t domain via the FOO_disable_trans boolean. EG to run Apache without restrictions you would type the above commands.
/etc/init.d/httpd restart
Chris Samual writes a good summary of Peter Gutmann's analysis of the cost of Vista (in terms of DRM).
The following paragraph in the article however seemed more interesting to me:
Once a weakness is found in a particular driver or device, that driver will have its signature revoked by Microsoft, which means that it will cease to function (details on this are a bit vague here, presumably some minimum functionality like generic 640x480 VGA support will still be available in order for the system to boot). This means that a report of a compromise of a particular driver or device will cause all support for that device worldwide to be turned off until a fix can be found.
Now just imagine that you want to cause widespread disruption - a DOS (Denial Of Service) attack against Windows users. What better option than to cause most of them to have hardware that's not acceptable to the OS? I expect that there will be many instances of security holes in drivers and hardware being concealed by MS because they can't afford the PR problems resulting from making millions of machines cease functioning. But just imagine that someone finds hardware vulnerabilities in a couple of common graphics drivers or pieces of hardware and publicly releases exploits shortly before a major holiday. If it's public enough (EG posted to a few mailing lists and faxed to some major newspapers) then MS would be forced to invoke the DRM measures or lose face in a significant way. Just imagine the results of stopping 1/3 of machines working just before Christmas!
Of course after the first few incidents people will learn. It shouldn't be difficult to configure a firewall to prevent all access to MS servers so that they can't revoke access, after all our PCs are important enough to us that we don't want some jerk in Redmond just turning them off. Of course disabling connections to MS would also disable security updates - but we all know that usability is more important than security to the vast majority of users (witness the number of people who happily keep using a machine that they know to be infected with a virus or trojan).
If this happens and firewalling MS servers becomes a common action, I wonder if MS will attempt the typical malware techniques of using servers in other countries with random port numbers to get past firewalls. Maybe Windows updates could be spread virally between PCs, this method would allow infecting machines that aren't connected to the net via laptops.
Finally, I recommend that people who are interested in such things read Eastern Standard Tribe by Cory Doctorow, he has some interesting ideas about people DOSing corporations that they work for which seem surprisingly similar to what MS is doing to itself. I'll post about my own observations of corporations DOSing themselves in the near future.
I'm in the process of converting my Fedora/rawhide laptop to Debian.
On Fedora the AES encrypted filesystems deliver about 38MB/s read speed according to dd. On Debian the speed is 2.4MB/s when running Xen and 2.7MB/s when not running Xen. The tests were done on the same block device.
Debian uses a SMP kernel (there are no non-SMP kernels in Debian), but I don't expect this to give an order of magnitude performance drop. Both systems use i686 optimised kernels.
Update: As suggested I replaced the aes module with the aes_586 module. Unfortunately it made no apparent difference.
Update2: As suggested by a comment I checked the drive settings with hdparm and discovered that my hard drive was not using DMA. After I configured the initramfs to load the piix driver first it all started working correctly. Thanks for all the suggestions, I'll post some benchmarks of encryption performance in a future blog entry.
On a mailing list some questions were asked about disk encryption, I decided to blog the answer for the benefit of others:
What type of encryption would be the strongest? the uncrackable if you will? im not interested in DES as this is a US govt recommendation - IDEA seems good but what kernel module implements this?
The US government (which incidentally employs some of the best cryptologists in the world) recommends encryption methods for data that is important to US interests (US military and banking operations for starters). Why wouldn't you want to follow those recommendations? Do you think that they are putting back-doors in their own systems?
If they were putting in back-doors do you think that they would use them (and potentially reveal their methods) for something as unimportant as your data?
I think that if the US military wanted to apply a serious effort to breaking the encryption on your data then you would have an assortment of other things to worry about, most of which would be more important to you than the integrity of your data.
I've read some good things about keeping a usb key for system boot so that anything on the computer itself is unreadable without the key - but thats simply just a physical object - I'd like both the system to ask for the passphrase for the key as well as needing the usb key
I believe that can be done with LUKS, however it seemed broken last time I experimented with it so I've stuck with the older operation of cryptsetup.
What kind of overheads does something like this entangle? - will my system crawl because of the constant IO load of the disk?
My laptop has a Pentium-M 1.7GHz and a typical laptop drive. The ratio of CPU power to hard drive speed is reasonable. For most operations I don't notice the overhead of encryption, the only problem is when performing CPU intensive IO operations (such as bzip compression of large files). When an application and the kernel both want to use a lot of CPU time then things can get slow.
More recent machines have a much higher ratio of CPU power to disk IO as CPU technology has been advancing much faster than disk technology. A high-end desktop system might have 2-3x the IO capacity
of my machine, but a single core would have 2-3x the computer power of the CPU in my laptop and for any system you might desire nowadays 2 cores is the minimum. Single-core machines are still on sale and still work well for many people - I am still deploying Pentium-3 machines in new installations, but for machines that make people drool it's all dual-core in laptops and one or two dual-core CPUs in desktop systems (with quad core CPUs on sale soon).
If you want to encrypt data on a P3 system with a RAID array (EG a P3 server) then you should expect some performance loss. But for a typical modern desktop system you shouldn't expect to notice any overhead.
Following from my 5 minute OSDC talk yesterday on 5 security improvements needed in Linux distributions I gave a 5 minute talk on installing SE Linux on Debian etch. To display the notes I formatted them such that they were in 24 line pages and used less at a virtual console to display them. The ultra-light laptop I was using has only 64M of RAM which isn't enough for a modern X environment and I couldn't be bothered getting something like Familiar going on it.
After base install you install the policy and the selinux-basics package:
# apt-get install selinux-basics selinux-policy-refpolicy-targeted
The following extra packages will be installed:
checkpolicy libsemanage1 mime-support policycoreutils python python-minimal
python-selinux python-semanage python-support python2.4 python2.4-minimal
selinux-utils
Suggested packages:
python-doc python-tk python-profiler python2.4-doc logcheck syslog-summary
The following NEW packages will be installed:
checkpolicy libsemanage1 mime-support policycoreutils python python-minimal
python-selinux python-semanage python-support python2.4 python2.4-minimal
selinux-basics selinux-policy-refpolicy-targeted selinux-utils
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 6362kB of archives.
After unpacking 41.5MB of additional disk space will be used.
Do you want to continue [Y/n]?
# fixfiles relabel
Files in the /tmp directory may be labeled incorrectly, this command
can remove all files in /tmp. If you choose to remove files from /tmp,
a reboot will be required after completion.
Do you wish to clean out the /tmp directory [N]? y
Cleaning out /tmp
/sbin/setfiles: labeling files under /
matchpathcon_filespec_eval: hash table stats: 14599 elements, 14245/65536 buckets used, longest chain length 2
/sbin/setfiles: labeling files under /boot
matchpathcon_filespec_eval: hash table stats: 19 elements, 19/65536 buckets used, longest chain length 1
/sbin/setfiles: Done.
title Debian GNU/Linux, kernel 2.6.17-2-686
root (hd0,1)
kernel /vmlinuz-2.6.17-2-686 root=/dev/x selinux=1 audit=1 ro enforcing=1
initrd /initrd.img-2.6.17-2-686
# id -Z
system_u:system_r:unconfined_t
# ps axZ |grep -v unconfined_t|grep -v kernel_t|grep -v initrc_tThe initial install of policy inserts modules to match installed software, if you install new software then you need to add new modules with the semodule command:
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t 1 ? Ss 0:02 init [2]
system_u:system_r:udev_t 1999 ? S.s 0:01 udevd --daemon
system_u:system_r:syslogd_t 3306 ? Ss 0:00 /sbin/syslogd
system_u:system_r:klogd_t 3312 ? Ss 0:00 /sbin/klogd -x
system_u:system_r:apmd_t 3372 ? Ss 0:00 /usr/sbin/acpid -c /etc
system_u:system_r:gpm_t 3376 ? Ss 0:00 /usr/sbin/gpm -m /dev/i
system_u:system_r:crond_t 3402 ? Ss 0:00 /usr/sbin/cron
system_u:system_r:local_login_t 3423 tty1 Ss 0:00 /bin/login --
system_u:system_r:local_login_t 3424 tty2 Ss 0:00 /bin/login --
system_u:system_r:getty_t 3425 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
system_u:system_r:getty_t 3426 tty4 Ss+ 0:00 /sbin/getty 38400 tty4
system_u:system_r:getty_t 3429 tty5 Ss+ 0:00 /sbin/getty 38400 tty5
system_u:system_r:getty_t 3430 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
system_u:system_r:dhcpc_t 3672 ? S.s 0:00 dhclient3 -pf /var/run/
# semodule -i /usr/share/selinux/refpolicy-targeted/apache.pp
security: 3 users, 7 roles, 824 types, 67 bools
security: 58 classes, 11813 rules
audit(1165532434.664:21): policy loaded auid=4294967295
# semodule -i /usr/share/selinux/refpolicy-targeted/bind.pp
security: 3 users, 7 roles, 836 types, 68 bools
security: 58 classes, 12240 rules
audit(1165532467.874:22): policy loaded auid=4294967295
# restorecon -R -v /etc /usr/sbin /var/run /var/log
restorecon reset /etc/bind context system_u:object_r:etc_t->system_u:object_r:named_zone_t
restorecon reset /etc/bind/named.conf context system_u:object_r:etc_t->system_u:object_r:named_conf_t
[...]
restorecon reset /etc/apache2 context system_u:object_r:etc_t->system_u:object_r:httpd_config_t
restorecon reset /etc/apache2/httpd.conf context system_u:object_r:etc_runtime_t->system_u:object_r:httpd_config_t
[...]
restorecon reset /usr/sbin/named context system_u:object_r:sbin_t->system_u:object_r:named_exec_t
restorecon reset /usr/sbin/apache2 context system_u:object_r:sbin_t->system_u:object_r:httpd_exec_t
restorecon reset /usr/sbin/rndc context system_u:object_r:sbin_t->system_u:object_r:ndc_exec_t
restorecon reset /usr/sbin/named-checkconf context system_u:object_r:sbin_t->system_u:object_r:named_checkconf_exec_t
[...]
restorecon reset /var/run/bind context system_u:object_r:var_run_t->system_u:object_r:named_var_run_t
restorecon reset /var/run/bind/run context system_u:object_r:var_run_t->system_u:object_r:named_var_run_t
restorecon reset /var/run/bind/run/named.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:named_var_run_t
restorecon reset /var/run/motd context system_u:object_r:initrc_var_run_t->system_u:object_r:var_run_t
restorecon reset /var/run/apache2 context system_u:object_r:var_run_t->system_u:object_r:httpd_var_run_t
restorecon reset /var/run/apache2/cgisock.3558 context system_u:object_r:var_run_t->system_u:object_r:httpd_var_run_t
restorecon reset /var/run/apache2.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:httpd_var_run_t
restorecon reset /var/log/apache2 context system_u:object_r:var_log_t->system_u:object_r:httpd_log_t
restorecon reset /var/log/apache2/error.log context system_u:object_r:var_log_t->system_u:object_r:httpd_log_t
restorecon reset /var/log/apache2/access.log context system_u:object_r:var_log_t->system_u:object_r:httpd_log_t
# killall -9 apache2
# /etc/init.d/apache2 start
Starting web server (apache2)....
# /etc/init.d/bind9 restart
Stopping domain name service...: bind.
Starting domain name service...: bind.
system_u:system_r:httpd_t 3833 ? Ss 0:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t 3834 ? S 0:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t 3839 ? Sl 0:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t 3841 ? Sl 0:00 /usr/sbin/apache2 -k start
system_u:system_r:named_t 3917 ? Ssl 0:00 /usr/sbin/named -u bind
Yesterday I gave a presentation at OSDC in Melbourne about my Postal mail server benchmark suite. The paper was about my new benchmark program BHM for testing the performance of mail relay systems and some of the things I learned by running it. I will put the paper on my Postal site in the near future and also I'll release a new version of Postal with the code in question very soon.
Today at OSDC I gave a 5 minute talk on 5 things that need to be improved in the security of Linux distributions.
In a comment on my post more about securing an office someone suggested using biometrics. The positive aspect of biometrics is that they can't be lost, no-one is accidentally going to leave a finger or an eye in their car while they go to a party while other authentication devices are regularly lost in such a manner.
The down-side is that having your finger or eye stolen would be a lot less pleasant than having a USB device, swipe-card, key, or other security device stolen. I think that it's good to have an option of surrendering your key when under threat (for the person who might be attacked at least).
Rumor has it that some biometric sensors look for signs of life (EG temperature and pulse), but I believe that these could be faked with a suitable amount of effort. A finger attached to a mini heart/lung machine should make it possible to pass the temperature and pulse checks (although I don't think that I have access to any data that is important enough to justify such effort on the part of an attacker).
One thing that biometrics could be useful for is screen-blankers. It would be good to be able to have a screen-blanker for your computer that operates when you go to get a coffee. For a period of 10 minutes after leaving a biometric method could be used to re-enable access. After that time a different method would ave to be used. This gives the convenience of biometrics for when you need it most (the many short trips away from your computer that you make during the day) but removes the benefit for an attacker who might consider removing part of your body. Also I am not convinced in the general security of biometrics. There are claims that you can make a finger based on a fingerprint which can fool a biometric sensor. If those claims are correct then a biometric sensor would still work for a coffee break (presumably you are not far away and will be back soon, and other people are in the area). The coffee break security is usually to prevent casual snooping such as colleagues who want to see what was on your screen but not actually do anything invasive to get it. Another benefit of biometrics for a screen saver is that although I trust people in the same office as me (whichever office that may be) not to try anything when they might get caught I still don't want them shoulder-surfing my password. Replacing the trivial authentication cases with a fingerprint reader would prevent that.
In the KDE 1.x days I had a shell script launched when the lid closed on my laptop which would lock the screen (the screen-saver ran in the background and a signal could make it lock the screen). This meant that I could merely close the lid of my laptop to lock the screen, this is fast and easy and also is not immediately recognised as locking the screen. Some people get offended if you lock your laptop screen when in their presence as they think that you should trust them enough to leave your most secret data open to them (generally people who aren't serious about computers - I'm sure that the same people would happily lock their diary if I was ever in the same room as it). Being able to lock the screen in a non-obvious way is a security benefit.
Regarding the comment about using a USB device to store passwords, there are two problems with this, one is that all passwords will be available all the time, this means a program that is permitted to access password A would also be given access to password B. The other is that the passwords can be accessed easily. The ideal solution is to have an encryption device that uses public key cryptography and stores the private keys on the device with no way of removing them. It would also permit the user to authorise each transaction.
I would like to see a USB device that stores multiple GPG keys and implements the GPG algorithm (with no way for anyone with less resources than the NSA to extract the keys). The device would have a display and a couple of buttons. When it is accessed it would display messages such as "signing attempt on key 1" and allow me to press a button to authorise or reject that operation.
This means that if I insert the key to sign an email I won't have a background trojan start issuing sign and decrypt commands. The only viable attack that would be permitted is the case where I want to sign a message and my message is sent to /dev/null and a message from an attacker is signed again. The non-arrival of my original message would hopefully alert me to this problem. I am not aware of any hardware which supports these functions.
Also I have just received a couple of RSA SecurID tokens as a sample. An RSA representative phoned me to ask about my use of the tokens, I said that I am an independent consultant and I have been having trouble getting my clients to accept my recommendations to use such devices and that I want to implement them on a test network so that I can give more detailed advice to my clients and hopefully get them to improve their security. For some reason the RSA rep found that funny, but I got my sample hardware so it's fine.
My post about securing an office received many comments, so many that I had to write another blog entry to respond to them and also add some other things I didn't think of before.
One suggestion was to use pam_usb to store passwords on a USB device. It sounds like it's worth considering, but really we need public key encryption. I don't want to have a USB device full of keys, I want a USB device that runs GPG and can decrypt data on demand - the data it decrypts could be a key to unlock an entire filesystem. One thing to note is that USB 2.0 has a bandwidth of 30MB/s while the IDE hard drive in my Thinkpad can sustain 38MB/s reads (at the start - it would be slower near the end). This means that I would approximately halve the throughput on large IOs by sending all the data to a USB device for encryption or decryption. Given that such bulk IO is rare this is feasible. There are a number of devices on the market that support public-key encryption, I would be surprised if any of them can deliver the performance required to encrypt all the data on a hard drive. But this will happen eventually.
Bill made a really good point about firewire. I had considered mentioning it in my post but refrained due to a lack of knowledge of the technology (it's something that I would disable on my own machines but in the past I couldn't recommend that others disable without more information). Could someone please describe precisely which 1394 (AKA Firewire) modules should be disabled for a secure system? If you don't need Firewire then it's probably best to just disable it entirely.
To enable encryption in Fedora Core 6 you need something like the following in /etc/crypttab:
home_crypt /dev/hdaX /path/to/keyDebian uses the same format for /etc/crypttab.
swap /dev/hdaX /dev/random swap
One issue that is rarely considered is how to deal with office break-ins for the purpose of espionage. I believe that this issue has been solved reasonably well for military systems, but many of the military solutions do not apply well to civilian systems - particularly the use of scary dudes with guns. Also most office environments don't have the budget for any serious security, so we want to improve things a bit without extra cost. Finally the police aren't interested in crimes where an office is burgled for small amounts of cash and items of minor value, it gets lost in the noise of junky burglaries, so prevention is the only option.
Having heard more information about such break-ins than I can report, I'll note a few things that can be done to improve the situation - some of which I've implemented in production.
The most obvious threat model is theft of hard drives. The solution to this is to encrypt all data on the drives. The first level of this is to simply encrypt the partitions used for data, support for this is available in Fedora Core 6 and has been in Debian for some time. The more difficult feature is encrypting the root filesystem, encrypting root means that important system files such as /etc/shadow are encrypted. Also if the root filesystem is encrypted then an attacker can't trivially subvert the system by replacing binaries. An unencrypted root filesystem on a machine that is left turned off overnight (or for which an unexpected reboot won't be treated seriously) allows an attacker to remove the drive, replace important system files and then re-install it. If the machine is booted from removable media (EG USB key) which contains the kernel and the key for decrypting the root filesystem then such attacks are not possible. Debian/unstable supports an encrypted root filesystem, but last time I tried the installer there did not appear to be any good support for booting from USB (but given the flexibility of the installer I think it's within the range of the available configuration options). I have run Fedora systems with an encrypted root filesystem for a few years, but I had to do some gross hacks that were not of a quality that would be accepted. With the recent addition of support for encrypted filesystems in Fedora it seems likely that some such patches could be accepted - I would be happy to share my work with anyone who wants to do the extra work to make it acceptable for Fedora.
Once the data is encrypted on disk the next thing you want to do is to make the machines as secure as possible. This means keeping up to date with security patches even on internal networks. I think that a viable attack method is to install a small VIA based system in the switch cabinet (no-one looks for new equipment appearing without explanation) that sniffs an internal (and therefore trusted) network and proxies it to a public network. This isn't just an issue of securing applications, it also means avoiding insecure protocols such as NFS and AoE for data that is important for your secrecy or system integrity.
An option for using NFS is to encrypt it with IPSEC or similar technology. AoE can be encrypted with cryptsetup in the same way as you encrypt hard drive partitions, it doesn't use IP so IPSEC won't work but it is a regular block device so anything that encrypts block devices will work. I have been wondering about how well replay attacks might work on an encrypted AoE or iSCSI device.
Security technologies such as SE Linux are good to have as well. An attacker who knows that a server has encrypted hard drives might try cracking it instead. A thief who has stolen a laptop and knows that it has an encrypted drive can keep it running until future vulnerabilities are discovered in any daemons that accept data from the network (of course if you have enough technology you could sniff the necessary data from the system bus and from RAM while it's running - but most attackers won't have such resources). I have considered running a program on my laptop that would shut it down if for a period of 48 hours I didn't login or un-blank the screen, that would mean that if it was stolen then the thief would have 48 hours to try and crack it.
Prevent access to some hardware that you don't need. If you allow the system to load all USB drivers then maybe a bug in such a driver could be exploited to crack it. Remember that in a default configuration USB drivers will be loaded when a device is inserted (which is under control of an attacker) and the device will use data from the attacker's hardware (data of low integrity being accessed by code that has ultimate privilege). Turning off all USB access is an option that I have implemented in the past. I have not figured out a convenient way of disabling all USB modules other than the few that I need, I have considered writing a shell script to delete the unwanted modules that I can run after upgrading my kernel package.
Once these things have been done the next issue is securing hardware. Devices to monitor keyboard presses have been used to steal passwords. The only solution I can imagine for this is to use laptops on people's desks and then store them in a safe overnight, unfortunately laptops are still quite a bit more expensive than desktop machines and consequently they are mostly used as status symbols in offices. Please let me know if you have a better idea for solving the key-logging problem.
For servers there is also a problem with keyboard sniffing. Maybe storing the server's keyboard in a safe would be a good idea.
Security monitoring systems are a good idea, unfortunately they can be extremely expensive. There has already been at least one recorded case of a webcam being used to catch a burglar. I believe that this has a lot of potential. Get a webcam server setup with some USB hubs and cameras and you can monitor a small office from all angles. When the office is empty you can have it GPG encrypt pictures and send them off-site for review in the case of burglary. You could also brick the server into a wall (or make it extremely physically secure in other ways) so that the full photo record would be available in the case of damaged phone lines, and to give more pictures than the upload bandwidth of an ADSL link would allow (512Kb/s doesn't allow uploading many pictures - no-where near the capacity of a few high-resolution web-cams).
This is just a few random thoughts, some things I've done, some things I plan to do, and some that just sound like fun. I expect comments telling me that I have missed some things. I may end up writing a series of articles on this topic.
PS I've uploaded day 32 of the beard (which was taken yesterday). Last night at a LUV meeting I was asked to stand in front of the audience to show them my beard. I had imagined that they might have seen it enough through my blog, but apparently not.
Today I discovered a bug in one of my programs, it called system() and didn't correctly escape shell eta-characters. Fortunately I had written custom SE Linux policy for it which did domain_auto_trans(foo_t, shell_exec_t, very_restricted_t) so there was no possibility of damage.
The log files (which were not writable by the daemon by both SE Linux access control and Unix permissions) indicated that no-one had attempted to exploit the bug.
