Categories

Donate

Advert

Running the Net After a Collapse

I’ve been thinking about what we need in Australia to preserve the free software community in the face of an economic collapse (let’s not pretend that the US can collapse without taking Australia down too). For current practices of using the Internet and developing free software to continue it seems that we need the following essential things:

  1. Decentralised local net access.
  2. Reliable electricity.
  3. Viable DNS in the face of transient outages.
  4. Reasonably efficient email distribution (any message should be delivered in 48 hours).
  5. Distribution of bulk binary data (CD and DVD images of distributions). This includes providing access at short notice.
  6. Mailing lists to provide assistance which are available with rapid turn-around (measured in minutes).
  7. Good access to development resources (test machines).
  8. Reliable and fast access to Wikipedia data.
  9. A secure infrastructure.

To solve these I think we need the following:

  1. For decentralised local net access wireless is the only option at this time. Currently in Australia only big companies such as Telstra can legally install wires that cross property boundaries. While it’s not uncommon for someone to put an Ethernet cable over their fence to play network games with their neighbors or to share net access, this can’t work across roads and is quite difficult when there are intervening houses of people who aren’t interested. When the collapse happens the laws restricting cabling will all be ignored. But it seems that a wireless backbone is necessary to then permit Ethernet in small local areas. There is a free wireless project wireless.org.au to promote and support such developments.
  2. Reliable electricity is only needed for server systems and backbone routers. The current model of having huge numbers of home PCs running 24*7 is not going to last. There are currently a variety of government incentives for getting solar power at home. The cheapest way of doing this is for a grid-connected system which feeds excess capacity into the grid – the down-side of this is that when grid power goes off it shuts down entirely to avoid the risk of injuring an employee of the electricity company. But once solar panels are installed it should not be difficult to convert them to off-grid operation for server rooms (which will be based in private homes). It will be good if home-based wind power generation becomes viable before the crunch comes, server locations powered by wind and solar power will need smaller batteries to operate overnight.
    In the third-world it’s not uncommon to transport electricity by carrying around car batteries. I wonder whether something similar could be done in a post-collapse first-world country with UPS batteries.
    Buying UPSs for all machines is a good thing to do now, when the crunch comes such things will be quite expensive. Also buying energy-efficient machines is a good idea.
  3. DNS is the most important service on the net. The current practice is for client machines to use a DNS cache at their ISP. For operation with severe and ongoing unreliability in the net we would need a hierarchy of caching DNS servers to increase the probability of getting a good response to a DNS request even if the client can’t ping the DNS server in question. One requirement would be the use of DNS cache programs which store their data on disk (so that a transient power outage on a machine which has no UPS won’t wipe out the cache), one such DNS cache is pdnsd [1] (I recall that there were others but I can’t find them at the moment). Even if pdnsd is not the ideal product for such tasks it’s a good proof of concept and a replacement could be written quickly enough.
  4. For reasonably efficient email distribution we would need at a minimum a distribution of secondary MX records. If reliable connections end to end aren’t possible then outbound smart-hosts serving geographic regions could connect to secondary MX servers in the recipient region (similar to the way most mail servers in Melbourne used to use a university server as a secondary MX until the sys-admin of that server got fed up with it and started bouncing such mail). Of course this would break some anti-spam measures and force other anti-spam measures to be more local in scope. But as most spam is financed from the US it seems likely that a reduction in spam will be one positive result of an economic crash in the US.
    It seems likely that UUCP [2] will once again be used for a significant volume of email traffic. It is a good reliable way of tunneling email over multiple hops between hosts which have no direct connectivity.
    Another thing that needs to be done to alleviate the email problem is to have local lists which broadcast traffic from major international lists, this used to be a common practice in the early 90’s but when bandwidth increased and the level of clue on the net decreased the list managers wanted more direct control to allow them to remove bad addresses more easily.
  5. Distributing bulk data requires local mirrors. Mirroring the CD and DVD images of major distributions is easy enough. Mirroring other large data (such as the talks from www.ted.com) will be more difficult and require more manual intervention. Fortunately 750G disks are quite cheap nowadays and we can only expect disks to become larger and cheaper in the near future. Using large USB storage devices to swap data at LUG meetings is a viable option (we used to swap data on floppy disks many years ago). Transferring CD images over wireless links is possible, but not desirable.
  6. Local LUG mailing lists are a very important support channel, the quality and quantity of local mailing lists is not as high as it might be due to the competition with international lists. But if a post to an international list could be expected to take five days to get a response then there would be a much greater desire to use local lists. Setting up local list servers is not overly difficult.
  7. Access to test machines is best provided by shared servers. Currently most people who do any serious free software development have collections of test machines. But restrictions in the electricity supply will make this difficult. Fortunately virtualisation technologies are advancing well, much of my testing could be done with a few DomU’s on someone else’s server (I already do most of my testing with local DomU’s which has allowed me to significantly decrease the amount of electricity I use).
    Another challenge with test machines is getting the data. At the moment if I want to test my software on a different distribution it’s quite easy for me to use my cable link to download a DVD image. But when using a wireless link this isn’t going to work well. Using ssh to connect to a server that someone else runs over a wireless link would be a much more viable option than trying to download the distribution DVD image over wireless!
  8. Wikipedia.org is such an important resource that access to it provides a significant difference in the ability to perform many tasks. Fortunately they offer CD images of Wikipedia which can be downloaded and shared [3].
  9. I believe that it will be more important to have secure computers after the crunch, because there will be less capacity for overhead. Currently when extra hardware is required due to DOS attacks and systems need to be reinstalled we have the resources to do so. Due to the impending lack of resources we need to make things as reliable as possible so that they don’t need to be fixed as often, this requires making computers more secure.
April 19th, 2008 | Category: Internet | 2 comments

Partitioning a Server with NSA SE Linux

Notes

I presented this paper at Linux Kongress 2002. Since that time virtualisation systems based around VMWare, Xen, and the hardware virtualisation in recent AMD and Intel CPUs has really taken off. The wide range of virtualisation options makes this paper mostly obsolete, and what isn’t obsoleted by that is obsoleted by new developments in SE Linux policy which change the way things work. One thing that’s particularly worth noting is the range of network access controls that are now available in SE Linux.

This is mostly a historical document now.

http://lsm.immunix.org/ is defunct, since about 2004.

Partitioning a Server with NSA SE Linux

Russell Coker <russell@coker.com.au>
http://www.coker.com.au/

Abstract

The requirement to purchase multiple machines is often driven by the need to have multiple administrators with root access who do not trust each other.

Having large numbers of expensive under-utilised servers with the associated management costs is not ideal.

I will describe my solution to this problem using SE Linux [1] to partition a server such that the “root” users can’t access each other’s files, kill each other’s processes, change passwords for each other’s users, etc.

DOS attacks will still be possible by excessive use of memory and CPU time, but apart from that all the benefits of separate hardware will be provided.

Introduction

SE Linux dramatically improves the security of a Linux system by adding another layer of security in addition to the default Unix permissions model. This is accomplished by firstly assigning a type to every file, device, network socket, etc. Then every process has a domain and the level of access permitted to a type is determined by the domain of the process that is attempting the access (in addition to the usual Unix permission checks). Domains may only be changed at process execution time. The domain may automatically be changed when a process is executed based on the type of the executable program file and the domain of the process that is executing it, or a privileged process may specify the new domain for the child process.

In addition to the use of domains and types for access control SE Linux tracks the identity of the user (which will be system_u for processes that are part of the operating system or the Unix username) and the role. Each identity will have a list of roles that it is permitted to assume, and each role will have a list of domains that it may use. This gives a high level of control over the actions of a user which is tracked through the system. However in this paper I am not using any of the identity or role features of SE Linux (they merely give an extra layer of security on top of what I am researching). So I will not mention them again.

For a detailed description of how SE Linux works I recommend reading the paper Peter Loscocco presented at OLS in 2001[1]. For the details of SE Linux policy configuration I recommend Stephen Smalley’s paper[2].

The problem of dividing a hardware resource that is expensive to purchase and manage among many users is an ongoing issue for system administrators. In an ISP hosting environment or a software development environment a common method is to use chroot environments to partition a server into different virtual environments. I have devised some security policies and security server programs to implement a chroot environment on SE Linux with advanced security offering the following features:

  1. An unpriviledged user (chroot administrator) can setup their own chroot environment, create accounts, run sshd, let ordinary users login via ssh, and do normal root things to them without needing any help from the administrator.
  2. Processes outside the chroot environment can see the processes in the chroot, kill them, strace them, etc. Also the user can change the security labels of files in their chroot to determine which of the files are writable by a process in the chroot environment (this can be done from outside the chroot environment or from a priviledged process within the chroot environment).
  3. Processes inside the chroot can’t see any system processes, or any of the user’s processes that are outside the chroot. They can see which PID’s are in use, but that doesn’t allow them to see any information on the processes in question or molest such processes. The chroot processes won’t be allowed to read any files or directories labelled with the type of the user’s home directory. This is so that if the wrong files are accidentally moved into the chroot environment then they won’t be read by chroot processes.
  4. The administrator can set a user’s account for multiple independant chroot environments. In such a case processes inside one chroot can’t interfere with processes in other in any way, and all their files will be in different types. This prohibits a nested chroot, but I think that there’s no good cause for nested chroot’s anyway. If someone has a real need for nested chroot’s they could always build them on top of my work – it would not be particularly difficult.
  5. The user will have the option of running a priviledged process inside their chroot which can do anything to files or processes in the chroot (even files that are read-only to regular chroot processes) but which can’t do anything outside the chroot. Also if this process runs a program that is writable by a regular chroot process then it runs it in the regular chroot process domain. This is to prevent a hostile user inside the chroot from attacking the chroot administrator after tricking them into running a compromised binary.

A basic chroot environment has several limitations, the most important of which is that a process in the chroot environment can kill any process with the same UID (or in the case of a root process any process with any UID) outside the chroot environment. The second major limitation is that root access is needed to call the chroot() system call to start a chroot environment and this gives access to almost everything else that you might want to restrict. There are a number of other limitations of chroot environments, but they are all trivial compared to these.

One method of addressing this issue is that of GR security [3]. GR Security locks down a chroot environment tightly, preventing fchdir(), mount(), double-chrooting, pivot_root(), and access to non-chroot processes (or processes in a different chroot). It also has the benefit that no extra application configuration is required. However it has the limitation that you have very limited ability to configure the capabilities of the chroot, and it has no solution to the problem of requiring root access to setup the chroot environment.

Another possible solution to the problem is that of BSD Jails [4]. A jail is a chroot environment that prevents escape and also prevents processes in the jail from interfering with processes outside the jail. It is designed for running network servers and allows confining the processes in a particular jail to a single IP address (a very handy feature that is not available in SE Linux at this time and which I have to emulate in a shared object). Also the jail authors are working on a jailinit program which is similar to init but for jails (presumably the main difference is that it doesn’t expect to have PID==1), this program should work well for chroot environments in SE Linux too.

Another possible solution is to use User-Mode Linux [5]. UML is a port of the Linux kernel to the Linux system call interface. So it can run a kernel as a user (UID!=0) application using regular files on the file system for storage. One problem with UML is that it is based around file system images on disk, so to access them without the UML kernel running you have to loopback mount them which is inconvenient. Also starting or stopping a UML image is equivalent to booting or shutting down a server (which is inconvenient if you just want to run a simple command like last). A final problem with UML for hosting is that using file systems for storage is inefficient, if you have 100 users who each might use 1G of storage (but who use on average 50M) you need 100G of disk space. With chroot based systems you would only need 5G of disk space. Finally backing up a file system image from a live UML setup will give a corrupted file system, backing up files from a chroot is quite safe.

Isolation of the Chroot

The first aim is to have the chroot environment be as isolated as possible from other chroot’s, from the chroot administrator, and from the rest of the system. This is quite easy as SE Linux defaults to denying access (apart from the system administration domain sysadm_t which has full access to see and kill processes, read files, etc).

For example pivot_root, is denied by not giving the sys_admin capability. Access to other processes is denied by not permitting access to read from the /proc directories, send signals, ptrace, etc. fchdir() is prevented because processes in the chroot don’t get access to files or directories outside the chroot because of the type labels, so it can only fchdir() back into the chroot! Mount and chroot accesses are also not granted to the chroot environment, nor is access to configure network interfaces.

The next aim is to make a chroot environment more secure than a non-SE system in full control of the machine. The first step to this is having critical resources such as hard drive block devices well out of reach of the chroot environment. With a default SE Linux security policy (which my work is based on) that is already achieved, a regular root process that is not chrooted will be unable to perform such access. This isolation of block devices, the boot manager, priviledged system processes (init, named, automount, and the mail server) from the rest of the system already makes a chroot environment on SE Linux more secure than that on a system without SE Linux, most (hopefully all) attacks against such critical parts of the system that would work on other systems will be defeated by SE Linux.

One problem that I still have not solved to my satisfaction is that of not requiring super-user access to initially create the chroot environment. I have developed policy modifications to allow someone to login as root (UID==0) in a non-chroot environment and not have access to cause any damage. So for my current testing I have started all chroot environments from a root login in a user domain as the chroot and mount operations require root privileges. For production use you would probably not want to give a user-domain root account to a user, so I am writing a SUID root program for running both mount and chroot to start a chroot environment and to run umount to end such an environment (after killing all the processes). It will take a configuration file listing the target directory, the bind mounts to setup, and the programs to run. One issue that I initially had with this was to make sure that it only runs on SE Linux (if SE Linux was removed but the application remained installed then you would grant everyone the ability to run programs as root in an unrestricted fashion through chrooting to the root directory). My current method of solving this is to execute /bin/false at the start of the program, if SE Linux blocks that execution then it indicates that SE Linux is in enforcing mode (otherwise the program ends). Also it directly checks for the presence of SE Linux (so if the administrator removes /bin/false then it won’t give a false positive). However this still leaves the corner case where an administrator puts the machine in permissive mode and removes /bin/false To avoid this the program will then try reading /etc/passwd which will always be readable on a functional Unix machine unless you have SE Linux (or some similar mechanism) in place. Before running chroot the wrapper will change directory to the chroot target and run “chroot .”. My policy prohibits the chroot program from accessing any directories outside the chroot environment to prevent it from chrooting to the wrong directory, thus an absolute path will not work. Chroot administrators would be confused by this, so the wrapper hides it from them.

I believe that this method will work, but I have not tested it yet.

Domains

It would be possible to create a SE Linux policy to allow a chroot to have all the different domains that the full environment has (IE a separate security domain for each daemon). However this would be a huge amount of work for me to write the policy and maintain it as new daemons become available and as new versions of daemons are released with different functionality. It would result in a huge policy (number of daemons multiplied by number of chroot environments could result in a large number of domains) which is currently held in non-pageable kernel memory. In a future version of SE Linux they plan to make it pageable, but the fact that a large policy has a performance impact will remain. Also the typical chroot administrator does not want the bother of working with this level of complexity. Finally the limited scope of a chroot environment (no dhcp client, no need to run fsck or administer RAID devices, etc) reduces the number of interactions that can have a security impact, and as a general rule there is a security benefit in simplicity as mistakes are less likely.

In my current policy I have a single domain for the main programs in the chroot environment. This domain has write access to files under /home, /var, /tmp, and anywhere else that the chroot administrator desires (they can change the type of files and directories at any time to determine where programs can write, the writable locations of /home, /var, and /tmp are merely default values that I recommend – they are not requirements). Typically the entire chroot would default to being writable when it is installed and the chroot administrator would be encouraged to change that according to their own security needs. In the case of a chroot setup with chroot(etbe, etbe_apache) the main domain will be called etbe_apache_t.

I have been considered having a separate domain for user processes inside the chroot so that they can only write to files under /home (for example) and not /var (which would only be writable by system processes). To implement this would require either an automatic domain transition rule to transform the domain when running a user shell (as opposed to a shell script run by a system program), or a modified sshd, ftpd, etc. Requiring that chroot administrators use modified versions of standard programs is simply not practical, most users would be unable to manage correct installation and would require excessive help from the system administrator, also it might require significant programming to produce modified versions of some login programs. This leaves the option of automatic transitions. Doing this would require that a chsh inside the chroot not allow changing the shell to /bin/sh or any other shell that would be used by system shell scripts, and that all shells listed in /etc/shells be labelled as user shells. This requires a significant configuration difference between the chroot setup and that of standard configurations, that is difficult to maintain because of distribution packages and graphical system administration tools that would tend to change them back.

I conclude that having a separate domain for user processes is not feasible.

The next issue is administration of the chroot. Having certain directories and files be read-only is great for security but a pain when it is time to upgrade! This is a common problem for administrators who use a read-only mount for their chroot environment. To solve this issue I have created a domain which has write privileges for all files in the chroot, for the example above the name of this domain would be etbe_apache_super_t. This domain also has control over all processes in the chroot (ability to see them, kill them, and ptrace them), while the processes in the chroot can not even determine the existance of such super processes. If this process executes a file that is writable by the main chroot domain then it will transition to the main chroot domain, so that if a trojan is run it will not be able to damage the read-only files. This protection is not perfect however, using the source command or “/bin/sh < script” to execute a shell script will result in it being run in the super domain. However I think that this is a small problem, tricking an administrator into redirecting input for a shell from a hostile script or using the source command is very difficult (but not impossible). However it is quite easy for an administrator to mistakenly give the wrong label to files and allow them to be written by the wrong people (I made exactly this mistake when I first set it up), so preventing the execution of binaries that may have been compromised is a good security measure.

Note, that this method of managing read-only files does not require that applications running in the chroot environment be stopped for an upgrade, unlike most other methods of denying write access to files that are in use.

To have a working chroot environment you need a number of device files to be present, pseudo-tty files (for logins and expect), /dev/random (for sshd), and others. The chroot administrator can not be permitted to create their own device nodes as this would allow them to create /dev/hda and change system data! So I have created a special mount domain which in this example would be named etbe_mount_t based on Brian May’s mount policy to allow bind mounts of these device nodes. This does have one potential drawback, if you are denying a domain access to device nodes solely by denying search access to /dev then bind mounts could be used to allow access in contravention of security policy! I could imagine a situation where someone would want to allow a domain to access the pseudo-tty it inherits from it’s parent but not open other pty’s of the same type, and implementing this by denying access to the /dev/pts. This is not something that I would recommend however. I believe that this is the best solution, as not having a user mount domain would require that either the system administrator create bind mounts (a process that has risks regarding sym-links etc), create special device nodes (having two different device nodes for the same device with different types is a security issue), or otherwise be involved in the setup of the chroot in a fashion that involves work and security risks.

In summary, if you have the bad idea of restricting access to the /dev directory to prevent access to device nodes then things will break for you, however there are many other ways of breaking such things so I think that the net result is that security will not be weakened.

To actually enter the chroot environment you need to execute the chroot() system call. To allow that I created a domain for chroot, which in this example will be called etbe_chroot_t, this domain is entered when the user domain etbe_t executes the chroot program. Then when this domain executes a file of type etbe_apache_ro_t or etbe_apache_rw_t it will transition to domain etbe_apache_t, and when it executes a file of type etbe_apache_super_entry_t it will transition to domain etbe_apache_super_t.

Types

The primary type used for labelling files and directories is for read/write files, in the case of a chroot setup by chroot(etbe, etbe_apache) the type will be etbe_apache_rw_t. It can be read and written by etbe_apache_super_t and etbe_apache_t domains, and read by the etbe_chroot_t and etbe_mount_t domains. It can also be read and written by the user domain etbe_t.

The type etbe_apache_ro_t is the same but can only be written by the user domain and etbe_apache_super_t.

To enter as domain etbe_apache_super_t I have defined a type etbe_apache_super_entry_t. The aim of this is to allow easy entry of the administration domain by a script, otherwise I might have chosen to have a wrapper program to enter the domain which prompts the user for which domain they want to enter. The wrapper program idea would have the advantage of making it easier for novice chroot administrators, and I may eventually implement that too so that users get a choice.

One problem I found when I initially setup a chroot was that when installing new Debian packages the post installation scripts (running in the etbe_apache_super_t domain) started a daemon (such as sshd) it would also start as etbe_apache_super_t, and then a user could login with that domain! To solve this problem I created a new type etbe_apache_dropdown_t, when the etbe_apache_super_t executes a program of that type it transitions to etbe_apache_t, so labelling the /etc/init.d directory (and all files it contains) with this type causes the daemons to be executed in the correct domain. The write access for this type is the same as that for etbe_apache_ro_t.

Configuring the Policy

I have based my policy for chroot environments around a single macro that takes two parameters, the name of a user domain, and the name of a chroot. For example if I have a etbe_t domain and I want to create a chroot environment for apache then I could call chroot(etbe, etbe_apache) to create the chroot.

This makes it convenient to setup for a basic chroot as all the most likely operations that don’t comprise a security risk are allowed. Naturally if you have different aims then you will sometimes need to write some more policy. One of my machines runs a chroot environment for the purpose of running Apache, it required an extra fourteen lines of SE policy configuration to allow the Apache log files to be accessed by other system processes outside the chroot (a script that runs a web log analysis program in particular).

The typical chroot environment used for an Internet server will probably require between 5 and 20 lines of extra policy configuration and will take an experienced administrator less than 30 minutes to setup. Of course these could be added to custom macros allowing bulk creation with ease, setting up 500 different chroot environments for Apache should not take more than an hour!

Here is my policy for an Apache web server run in the system_r role by the system init scripts that has read-only access to all files under /home (which is –bind mounted inside the chroot), and which allows logrotate to run the web log analysis scripts as a cron job.


# setup the chroot
chroot(initrc, apache_php4)
# allow apache to change UID/GID and to bind to the port
allow apache_php4_t self:capability { setuid setgid net_bind_service };
allow apache_php4_t http_port_t:tcp_socket name_bind;
allow apache_php4_t tmpfs_t:file { read write };
# allow apache to search the /home/user directories
allow apache_php4_t user_home_dir_type:dir search;
# allow apache to read files and directories under the users home dir
r_dir_file(apache_php4_t, user_home_type);
# allow logrotate to enter this chroot (and any other chroot environments
# that are started from initrc_t)
domain_auto_trans(logrotate_t, chroot_exec_t, initrc_chroot_t)
# this chroot is located under a users home directory so logrotate needs to
# search the home directory (x access in directory permissions) to get to it
allow logrotate_t user_home_dir_t:dir search;
# allow logrotate to search through read-only directories (does not need read
# access) and read the directories and files that the chroot can write (the
# web logs). NB I do not need to restrict logrotate this much – but why give
# it more than it needs?
allow logrotate_t apache_php4_ro_t:dir search;
r_dir_file(logrotate_t, apache_php4_rw_t)
# allow a script in the chroot to write back to a pipe created by crond
allow initrc_chroot_t { crond_t system_crond_t }:fd use;
allow initrc_chroot_t { crond_t system_crond_t }:fifo_file { read write };
allow apache_php4_t { crond_t system_crond_t }:fd use;
allow apache_php4_t { crond_t system_crond_t }:fifo_file { read write };

That’s 14 lines because I expanded it to make the policy clearer. Otherwise I would probably compress it to 10 lines.

Networking

The final issue is networking, the BSD Jail facility has good support for limiting network access via a single IP address per jail.

SE Linux lacks support for controlling networking in this fashion, server ports can only be limited by the port number. This is OK if different chroot environments provide different services. Also this works if you have an intelligent router in front of the server to direct traffic destined for different IP addresses to different ports on the same IP address (in which case the different chroot environments can be given permissions for different ports).

I have an idea for another solution to this problem which is more invasive of the chroot environment. The idea is to write a shared object to be listed in /etc/ld.so.preload which will replace the bind() system call. This will then communicate over a Unix domain socket (which would be accessed through a bind mount) to a server process run with system privileges, and it will pass the file descriptor for the socket to it. The server process will then use the accept_secure() system call to determine the security context of the process that is attempting the bind, it will then examine some sort of configuration database and decide whether to allow the bind, or whether to modify it. If the bind parameters have to be modified (for example converting a bind to INADDR_ANY to be a bind to a particular IP address) then it would do so. Then it would do a bind() system call and return a success code to the socket that connects to the application.

This support would be ideal as it would be easiest to automate and would allow setting up hundreds or thousands of chroot environments at the same time with ease.

Unfortunately I couldn’t get this code fully written in time for the publishing deadline.

Conclusion

I believe that I have achieved all my aims regarding secure development environments or other situations where there is no need to run network servers. The policy provides good security and allows easy management.

My current design for entering a chroot environment should work via a SUID root program, but I will have to test it. The current method of allowing unprivileged root logins has been tested in the field and found to work reasonably well.

Currently the only issue I have not solved to my satisfaction is that of binding chroot environments to specific IP addresses. Currently the best option that I have devised involves pre-loading a shared object into all processes in the chroot environment (which will inconveniance the user). But I have not yet implemented this so I am not certain that it will work correctly.

Obtaining the Source

Currently most of my packages and source are available at http://www.coker.com.au/selinux/ however I plan to eventually get them all into Debian at which time I may remove that site.

I have several packages in the unstable distribution of Debian, the first is the kernel-patch-2.4-lsm and kernel-patch-2.5-lsm packages which supply the Linux Security Modules http://lsm.immunix.org/ kernel patch. That patch includes SE Linux as well as LIDS and some of the OpenWall functionality. When I have time I back-port patches to older kernels and include new patches that the NSA has not officially released, so often my patches will provide more features than the official patches distributed by the NSA from http://www.nsa.gov/selinux/ or the patches distributed by Immunix. However if you want the official patches then these packages may not be what you desire.

From the selinux-small archive I create the packages selinux and libselinux-dev which are also in the unstable distribution of Debian.

Acknowledgments

Thanks to Dr. Brian May for reviewing this paper and providing advice.

Bibliography

April 19th, 2008 | Category: Papers | Leave a comment

SE Linux Saves

Here are links to some instances when SE Linux prevented exploits from working or mitigated their damage:

April 3rd, 2008 | Category: Computers | Leave a comment

Going Live with a Linux Server

Based on past mistakes by myself and others, here is a check-list before putting a Linux (or other Unix) server online:

  1. Run memtest86+ (or an equivalent program for other architectures) before going live, ideally run it before installing the OS. Run it again every time you upgrade the RAM.
  2. Reboot the machine after every significant change. EG if you install a new daemon then reboot it to make sure that the daemon starts correctly. It’s better to have 5 minutes of down-time for a scheduled reboot than a few hours of down-time after something goes wrong at 2AM.
  3. Make sure that every account that is used for cron jobs has it’s email directed somewhere that a human will see it. Make sure that root has it’s mail sent somewhere useful even if you don’t plan to have any root cron jobs.
  4. Make sure that ntpd is running and has at least two servers to look at. If you have a big site then run two NTP servers yourself and have each of them look to two servers in the outside world or one server and a GPS.
  5. Make sure that you have some sort of daily cron job doing basic log analysis. The Red Hat logwatch program is quite effective, then you need to have some way of making sure that you notice if an email stops being sent (getting 11 instead of 12 messages from logwatch in the morning won’t be noticed by most people).
  6. Make sure that when (not if) a hard drive in your RAID array dies then you will notice it.

Any suggestions on other things I can add?

January 23rd, 2008 | Category: Computers | 3 comments

Personal SEO

One problem many people encounter is the fact that they don’t appear on Google and other search engines the way that they like. If you have an uncommon name which is not referenced in any popular web pages then a single mention in a popular site can immediately become the top hit, this may not be the post you want (EG you send a dirty joke to some friends and it ends up on the archive of a popular mailing list). If you have a more common name then you may want to compete with other people who share the same name with similar problems. The solution to these problems is known as Search Engine Optimisation (or SEO).

  1. Recently to improve things in this regard I have registered the domain RussellCoker.com. Domains that end in .com are often regarded as authoritative sources of information on the topic in question, and are also often typed in to browsers. If you visit the RussellCoker.com domain then you’ll find that it’s quite bare, just links to some other things that I do. I will make it a little more user-friendly but the main aim is just having links.
  2. One thing that I have been doing for almost a decade is to include URLs of some of my web pages in my signature of email that I send. When I send messages to mailing lists with public archives (or when other people forward my mail to such lists) these links will become visible to search engines. So I now have thousands of links to my web site from hundreds of sites all over the world. Some of these links are old (which may make them more highly rated by search engines). This not only gives benefits for direct hits from search engines, but when people search for terms that are relevant to my work they will often hit archives of my mailing list postings, and then they will often see a benefit in visiting my web site.

Most strategies of SEO that apply to corporate web sites will also apply to individuals (do a web search and you’ll find many pages of advice on these issues). But the above two are the only ones I have discovered which apply specifically to individuals (registering an appropriate .com domain name if possible is a standard practice for companies and something that is done long before SEO is considered).

January 22nd, 2008 | Category: Internet | Leave a comment

How to Report an Email Problem

In my work I often receive problem reports from clients regarding their email service, here is some advice to help get the problem fixed as fast as possible:

Firstly problems sending mail and problems receiving mail are often unconnected and should be reported separately. If only one aspect of a problem is reported then probably only one will be fixed… Also receiving mail via POP or IMAP is separate to the mail transfer process.

For problems on mail transfer the following points should be addressed in any report to increase the speed of problem resolution. Don’t think of this as being for the benefit of the person who fixes your mail server, think of it as being for your own benefit in getting your email working again rapidly.

  1. Make sure that every complaint has a specific example. Saying “email doesn’t work for everyone” is not helpful, often when investigating some complaints I discover that email works for many people. Saying “email doesn’t work for John Smith and other people report problems too” is helpful, I can investigate John’s problem while knowing that it’s a symptom of a larger problem.
  2. For every report make sure that you list a sender and recipient email address for an instance of the problem. Saying that “alpha@example.com can’t send mail to bravo@example.com” is much more useful than saying “alpha@example.com can’t send mail to some people“.
  3. Whenever possible make sure that the problem can be reproduced by the person who is making the report. A report such as “John Smith can’t send email from his PC” is not nearly as helpful as “I can’t send email from my PC“, the reason is that I often require more information from the person who experienced the problem and going through a third-party slows things down.
  4. Make a careful note of the time of the problem. If you report that alpha@example.com can’t send mail to bravo@example.com and the logs show that such a message was correctly delivered at 9AM I will assume that the problem was mistakenly reported and not that maybe there was a problem which first occurred at 9:30AM.
  5. When noting the time make sure you note any discrepancies. If a problem occurs at 9AM and a bounce message reports a problem occurring at 10AM then please make sure to note both times when reporting the problem. Either or both times could be referenced in the log files and the more information you provide the better the chance that the problem will be fixed quickly.
  6. Most serious errors in email delivery have a code numbered from 550 to 559 with an error message. Any time you see a bounce message which includes text such as “Remote host said: 554” then please report all the rest of the text on that line, it will often tell me precisely what needs to be done to fix the problem.
  7. Any time a bounce or other error message includes a URL then please report it to me. Sometimes it takes me a significant amount of work to discover what I could have learned in a matter of seconds if I had the URL.
January 18th, 2008 | Category: Internet | Leave a comment

Hotel Rooms vs Apartments

One option that is often overlooked is the possibility of staying in an apartment instead of a hotel room. The difference (which is not always reflected in the name) is that a hotel room usually will have a fridge that is mostly filled with over-priced drinks and has no facilities for cooking and often no facilities for cleaning clothes. A recent disappointing trend is of hotels that have a “bar fridge” that is entirely filled with things that you have to pay for which have sensors such that if any of them are moved then you have to pay. This prevents you from moving the rubbish out of the way for the duration of your visit so that you can store your sandwiches there.

An apartment will ideally have a fridge which is entirely empty for you to use for storing food and ingredients for your own cooking (it will have a minimally supplied kitchen). Apartments tend not to have a fry-pan in the kitchen, the reason for this is that they are legally required to have a smoke detector and false-alarms cause lots of problems for everyone (often it starts with an insanely loud alarm in the room which annoys everyone who is in a nearby room). You can expect to have two pots of different sizes and a toaster for your cooking.

If you are after cheap travel then the thing to do is to have cereal for breakfast and sandwiches for lunch. Finding cheap places to have lunch in a new city can take time, and finding cheap places to eat lunch near tourist attractions is almost impossible.

Some apartments have a washing machine and dryer in the room, but it’s quite common to have communal facilities for washing clothes. In any case there will be some option for washing clothes that doesn’t cost an excessive amount of money.

Another significant difference that is commonly seen between apartments and hotels is the layout (which is dictated to a large degree by the size). An apartment may have walls partially or fully separating it into separate rooms. One apartment I stayed in had two separate bedrooms (with doors), a kitchen area, and a lounge/dining area which was separated from the rest of the apartment. That made it possible to have business meetings in the lounge area while someone slept in one of the bedrooms. Another apartment I once stayed in had the bed area partially separated from the lounge area, the wall didn’t extend the full distance but covered enough that a business associate who walked into the lounge probably wouldn’t notice the bed area. There is a significant difference in principle between inviting a business associate to the lounge area of an apartment and inviting them to a hotel room…

Apartments often tend to be more expensive than hotel rooms, they need more space for the kitchen and don’t drive revenue from a mini-bar or a hotel restaurant. One possibility for saving money could be to use some inflatable camping beds to sleep four people in an apartment that is designed for two. They try and discourage this by only having enough cutlery for two people and not having spare blankets, towels, etc (I’m sure that they would bill you extra if they caught you). In contrast hotel rooms often have an over-supply of towels and blankets as it’s easier to just fill every closet with them than to deal with requests from customers at odd times of the night.

January 12th, 2008 | Category: Travel | One comment

Public Transport in Melbourne

Tickets for Melbourne public transport can be purchased on any bus or tram. The trams have vending machines which only accept coins so you must have sufficient coins to pay for your ticket. Neither buses nor trams sell the cheaper tickets.

Tickets have to be validated every time you get on a bus or tram. The first time a ticket is validated it will have it’s expiry time and date printed on it.

For a Sunday there’s a Sunday Saver ticket which allows you to go everywhere (in both zone 1 and 2) for the entire day for less than the price of a regular daily zone 1 ticket. As of the 6th of January 2008 a Sunday saver ticket costs $2.90 while a ticket for 5 days of travel in zone 1 costs $28.00 (separate daily tickets cost more).

The best value for money is the 10 * 2 hour ticket (which costs the same as a 5 * daily ticket). I have been told that if you use a multiple 2 hour ticket a second time in one day outside the 2 hour interval then it will be valid for the rest of the day. This means that a 10 * 2 hour ticket will give the same result as a 5 * daily ticket if you use it that way. If your journeys tend to be shorter then it can last for more than 5 days. Also a 2 hour ticket that is validated after some time in the evening (I believe it’s 6PM) will be valid for the rest of the night (until 3AM or whenever the transport closes down).

January 6th, 2008 | Category: Melbourne | Leave a comment

Unique Names

Prior to wide-spread use of the Internet it was reasonable to expect that if you had a family name that was not really common and a given name that was also not really common then you might never meet someone else with the same combination of first and last names as yourself. I have never met anyone else named Russell Coker because Coker is not a really common family name and it seems that Russell was not overly common in the last 4+ decades. If you had a family name such as Smith, Ng, or Ali then the chance of having someone else with the same given name would be significant as those family names are so incredibly popular.

Even with names that are not known to be extremely popular name clashes happen, for example my sister is named Helen Coker, it doesn’t seem likely to be an overly common combination however there was another Helen Coker at the same high-school.

On the Internet however things are different. About 10 years ago I received an email from someone named Russell Coker who just wanted to say hello after having searched for his own name and found information on me. Shortly after that I found a third Russell Coker on the net (who didn’t respond to my email). It seems likely that even in the early days of the net I didn’t find everyone named Russell Coker, and it also seems quite likely that the number of Russell Coker’s on the net has increased significantly over the last 10 years. There could be dozens of Russell Coker’s although if they are using “Russell Coker” as their name on the net then I am unlikely to find them as it’s most likely that I’m the only Russell Coker to have the same email address and web site for 10 years – so my net presence probably squashes everyone else who uses that as their entire name.

A quick google search for “Russell J Coker” (John is my middle name) found one other person using that name, I also found a Russell D Coker, a Russell M Coker, a Russell N Coker, and two Russell R Coker’s (one of whom died in 2002).

It seems that if you don’t have a family name that is rarely used (EG Torvalds which was created recently) or a made-up first-name (which seems to be a popular trend nowadays) then you are going to encounter other people with the same name as you. Using an initial will significantly reduce the incidence of this, in my case if I used my middle initial then I would remove four out of five of the other living Russell Coker’s that are found by Google.

But as is the case with me it seems that many (most?) people will have name collisions no matter what they do.

As an attempt to increase my control over my name I have registered the domain RussellCoker.com. Not sure if it will do any good but it’s cheap enough and it’s worth a try.

December 6th, 2007 | Category: Internet | Leave a comment

Mobile Phone Safety

Safety Benefits of Mobile Phones

The benefits of being able to call emergency services from any location are obvious. It’s also a benefit for children to be able to call their parents at any time and without the need for change.

The ability to send videos and pictures that is included in all recent mobile phones is also a potential safety benefit. Children can send their parents pictures of the people they associate with which will deter such people from doing anything bad.

Problems With Current Mobile Phones

There has been a lot of publicity in recent times about the risks of children communicating with pedophiles over the Internet. I believe that the risks in this regard are minimal, children merely need to be supervised while using the net. I think it’s a much bigger problem is that anyone (including pedophiles) can call a child on their mobile phone, and in the case of modern phones they can exchange pictures and movies with the child! There have been many documented cases of this technology being used by teenagers to film gang violence and I believe that the incidence of teenagers making their own pornography (including videos of sexual assault) will only increase (I first wrote this document about four months before such a sexual assault was filmed and sold on DVD in Melbourne [1]).

Another significant problem is the theft of phones (which often takes the form of violent crime). For their own safety children should not be permitted to carry expensive items that can be sold easily!

Solutions to these Problems

Many of these problems can be greatly alleviated with current technology. Firstly transfer of video and pictures needs to be restricted, current phones already have configuration options to restrict which numbers may call the phone. What is needed is to have separate lists of numbers permitted to call the phone and to be called by the phone that are also separated by the type of call (voice call, video call, SMS, and video/picture SMS). A typical configuration for young children might only permit communication with relatives and emergency services. A typical configuration for older children might permit voice and text SMS communication with anyone but only permit video and picture communication with relatives and emergency services. These measures would greatly reduce the ability of pedophiles to communicate with children, and also prevent teenagers from distributing pornography and fight club movies.

Another necessary feature is the ability to restrict access to the Internet and 3G content. This has been requested by many adult customers to prevent accidentally incurring large bills. However phone companies have been refusing to do this, legislation will be required.

Such restrictions of phone use would also significantly reduce the incidence of phone theft. A phone that can only be used to call the parents of it’s owner is useless to a thief!

New Features

A new feature that is badly needed is the ability to make video calls to emergency services. In a medical emergency call a lot of time is spent describing the situation and that time could be saved if pictures were available. In the case of a crime in progress a criminal would be deterred if they knew that their picture was being sent directly to the police and stored for use as evidence at their trial.
It would require some moderately expensive new equipment to support emergency video calls and require some training of the people who receive the calls, but I am certain that the benefits outweigh the costs.

Every mobile phone has a unique ID number that it sends to the phone company when it registers. It would be easy for each phone company to keep a database of the ID numbers of all phones it sells and then when a phone is stolen it could be blocked from the network or traced by the police. A similar scheme was tried in the Netherlands where the police sent large numbers of SMS messages to stolen phones.

With a registry of stolen phones shared between all phone companies and a block on the use of stolen phones phone theft would drop dramatically.

Implementation of the Necessary Changes

Support for video calls to emergency services requires government funding. All the other suggestions I make on this page can be implemented without government involvement. It would be nice if phone companies would address these issues voluntarily, but based on past performance that seems unlikely. We probably need legislation to force them to do the right thing.

December 3rd, 2007 | Category: Safety | Leave a comment
« Newer Entries  
  Older Entries »