I've tried to use capabilities to run xntpd without excessive privilege. Not surprisingly, the only capabiity xntpd requires is cap_sys_time.

For this change to be useful, xntpd needs to run as a uid other than 0, otherwise it can overwrite files owned by root, regardless of what capabilities it has. This is no big deal - we just have to call setuid to change uid.

Here's the problem - if you have any programs that don't understand capabities, you have to run without SECURE_NO_SETUID_FIXUP or else they won't throw away privilege correctly. In that mode, changing to a non-zero uid clears the effective and permitted capability sets. This is no good since you now have insufficient privilege to do what you want, so you employ the following horrible hack. (Have your Unix barf-bag ready...)

fork
[Parent]	[Child]
setgroups	block, waiting for parent
setgid
setuid
unblock child
wait for child	catsetp(getppid, capabilities)
	exit

The child is still running as root with all capabities, so it can hand over cap_sys_time to the parent. The parent will then have a non-zero uid and a non-empty capability set.

This must have worked once since sucap relies on a similar trick, but it doesn't work now because of how init is started.

#define CAP_INIT_EFF_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
#define CAP_INIT_INH_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))

This results in all children of init running with cap_setpcap-i, so the child process cannot hand over cap_sys_time to the parent.

• __u32 flags; /* ext2 compatible file flags */
• __u32 cap_allowed; /* allowed capabilities */
• __u32 cap_forced; /* forced capabilities */

WHY everyone is trying to add low limits in design just to try to break then later ? 32, 64 or 128 WILL NOT be enough in long run. I can understood why capabilities in kernel are 32bit word:

1. they are checked quite often and so it should be doable FAST and
2. they can be extended in future without big fuzz (it's internal kernel structures so only few system calls should be changed)

On other hand once something added to filesystem, it's added to FILESYSTEM. Read "set in stone". It's VERY hard to fix something there. And starting of program is NOT time-critical operation. Even if you put capabilities in separate file and store inode number of that file in inode of capability-enabled file this will not slow process starting much (even if IMO it's overkill). So 32bit is not way to go and even 64 is not enough. IMHO anyway.

Well, there's a trade off here. If you could have 32 bits basically almost right away, and more would take longer, which would you choose? Also, keep in mind that more bits is not necessarily good. There is a *huge* complexity cost in maintaining capabilities. People have enough trouble keeping track of the 12 bits of permissions on a per file basis. This adds one or two orders of magnitude of more bits for every executable.

However, my knowledge of human nature being what it is, I agree with you that unless very strong measures are taken to control the virtual explosion of new capabilities people will want to add, we will need more bits. So I'd suggest either putting a hard limit on 32 bits, or budgeting 128 or 256 bits, since bits are relatively cheap once you exceed 32.

People who are interested developing capability source should seriously think about ways to control the complexity, though. If the user-mode management tools aren't good enough, capabilities will be a diaster, and their use could actualy decrease the overall security on a system.

I'd like to (potentialy) be able to control every system call through a capablity. I'm also a strong fan of MLS systems, it lets my paranoid side out when protecting systems:).

I'd suggest using an index reference to a table containing multiple capability lists. The set of usable capability lists is limited. Many inodes, but the number of uniqe capability lists would be rather low (20-30 most likely). Using a reference:

1. reduces the impact on an inode (8 bits would allow for 255 different capabilitiy lists - reference 0 represents no list)
2. centralizes control over what capability lists are allowed; multiple inodes would be able to reference the same capability list.
3. allows customization by the security administrator (users would not be able to create arbitrary lists)
4. Allows more capabilities to be added without impact to the inode structure, only the reference table support.

Some additional administrative information could be determined easily too - if a "link count" is updated each time an inode is given/removed a capability reference, then the total number of files making use of the capability list would be known; as well as any unused definitions.

I'm in the process of setting up a secured server system (using RSBAC) and I would like to run the web server in a compartment, without the ability use the exec system call. Yes this restricts a lot of CGI capability, but does allow the use of Java (as part of the server) and mod_perl. The web pages (and data files) will be stored at a security level below that of the server process.

This configuration would prevent any hack entry into the server (via bugs/ stack overflow, etc) from being able to do anything to the data (no write down). Without the exec, no shell process could be generated. The most that could be done is aborting the server process. Since these are usually children of a parent server, they would normally be restarted when needed (parent would have fork, and listen).

Extended capabilities would allow me to detect/prevent hacking output data by changing the server. Admittedly, it would not prevent replacing the functionality of a web server (say by loading a bogus Java/perl server and running it) but if the remaining capabilities prevented the use of the "listen" system call (only the parent server listens) then even this attack would be defeated. (The Apache server would have to be patched to drop the capability to use the listen system call after the fork).

Capabilities, Access Control Lists, Auditing, Mandatory Access Control and Information Labeling are specified in Posix 1003.1e / 1003.2c Draft Standard 17. DS17 was withdrawn. Nevertheless, implementations of other Unixes are based on DS17 or earlier drafts.While DS17 is not perfect, a lot of work surely has gone into Capabilities and ACLs. Most of it actually makes sense.

The specs are publicly available. I guess Casey Schaufler already posted the link; here it is again: http://www.guug.de/~winni/posix.1e/download.html.

As far as capabilities are concerned, it's important at least the user interface for manipulating ACLs is close to DS17. Having a completely different capability scheme on Linux makes no sense. Linux tries to be compatible with POSIX and other Unixes; I see no reason why capabilities should be an exception.

Provided that the user interface is similar to DS17, a capabilities table just adds complexity that doesn't pay off. The setfcap utility specified in 1003.2c manipulates individual capabilities.

The owner of a file may change the capabilities of a file (provided that he/she is capable of CAP_SETFCAP). This also affects the per-filesystem capabilities table. A capability table causes the same trouble when backing up / restoring a filesystem. Each file and its associated capabilities need to be backed up. Just backing up the index into the capabilities table doesn't make much sense. When restoring the file to another filesystem, a capability set corresponding to the capabilities of the file will probably need to be created ...

I am convinced a fixed set of capabilities is all we need. A limit of 32 may be too low; 64 seems perfectly reasonable to me. Capabilities are not meant to cure each and every security problem. Things like protecting /etc/shadow are really better dealt with by filesystem permissions.

64 capabilities require 3x64 bits for each inode. For future expansion, 3x128 seems a safe limit. Storing 128 more bytes in each inode is beyond limits. Most files won't use capabilities, so that would be a massive waste of disk space.

I propose to store a pointer to the capabilities of a file in each inode. On ext2, we already have i_file_acl, which points to the ACL of a file. Capabilities could be stored at the same location.

One possible implementation:

The ext2 part of the ACLs for Linux project at <acl.bestbits.at> uses i_file_acl (and i_dir_acl) as a pointer to a disk block that contains the ACL of a file. The very same disk blocks seem a natural place for storing capabilities. This adds some trouble in the ACL code (it interferes with the ACL cache), but is doable.

[Inodes with identical ACLs frequently share an ACL disk block. When an inode is associated with an ACL, the ACL is looked up in a hash table. If a suitable ACL disk block is found in the cache, that block is reused; otherwise, a new ACL disk block is created.]

An alternative for storing capabilities, ACLs, etc. is to implement a mechanism for storing arbitrary meta information (i.e., attribute lists) for inodes. Irix XFS supports that. Ext2 has no comparable mechanism, but the i_file_acl block approach may be good enough.

The SunWorld article ``Controlling Permissions with ACLs'' at http://www.sunworld.com/swol-06-1998/swol-06-insidesolaris.html and the Linux ACL project at http://acl.bestbits.at/ contain some more implementation ideas.

On several B2 rated systems, the shell IS capable of requesting level changes, and unless the shell is operating in the proper environment (capabilities, level, compartment, and process tree) then even the request for security change can be a violation. (BTW, the system calls for changing security environment has to be built into the shell - they don't work otherwise - see below)

On one system I use (Cray UNICOS), the shell cannot change security classifications without:

1. be a login shell with a parent process that is flagged as a security user entry point(telentd/sshd recieve these privilages).
2. have no subprocesses
3. have no open output files other than the controlling terminal (ie. don't redirect stderr to a disk file...)
4. have the permission to change (elevate) security access.
5. can not raise level above that of the user connection (ie. secure wire, labeled network connection).

At least two of these get broken with a web server:

1. a web server should not be labeled as a user entry point
4. the web server sould not be labeled as such.

There are other restrictions that can be applied by modifying the web server itself:

1. deny fork capability in children of the listening web server.
2. deny any open for write capability.
3. deny listen, bind, connect... capability in children of the parent web server (no new network connections will be allowed after fork).

"Trillium" is just one of lattest efforts among others to bring one more architecture into Linux. http://www.linuxia64.org/ It has been widely touted only because the target processor is made by intel, and so far unavailable.

Linux began as i386 operating system in 1991. Linux 1.0 had only "i386" in 1994.

At Linux 1.2.* series (1995) mainline kernel already supported:

• i386 (32 bits)
• Alpha (64 bits)
• SPARC (32 bits)
• MIPS (32 bits)

Now Linux 2.2 already supports:

• i386 (32 bits)
• Alpha (64 bits)
• SPARC (32 and 64 bits versions)
• MIPS (32 bits)
• PowerPC (32 bits)
• ARM (32 bits)
• M68K (32 bits)

Linux 2.3 (development series) carries already additionally:

• SH (a.k.a Hitachi H8) (32 bits)
• IA64 (64 bits)

In the works (but not in mainline source) I have heard also of:

• MIPS-64
• PowerPC-64
• HP-PA (http://www.thepuffingroup.com/parisc/)

• PowerPC (64 bits)
• MIPS (64 bits)
• SuperH (32 bits)

• Whatever processor VAX:en use
• 88k
• Crays (the non-vector models; I suspect that Linux doesn't would be very suitable on a vector-machine. But I could be wrong)
• AS/400 (something akin to the S/390 port; a virtual machine is needed because of the lack of memory protection in hardware)

I even had two of them :) But I couldn't find nice docs easily, so I didn't bother. I've now passed the machines on to a nutty NC guy (peter jones), maybe he'll have more luck.

The nicest way to do this port would be to get the motorotola vme reference boards, I hear mot.de still has them in stock. Don't forget a very large barf-bag to deal with the 88k iteslf, and a time machine to find anyone else on the planet who knows anything about them.

The AS/400 is more like a toaster than a computer. They take an interesting approach of implementing a protected machine via software 'trust'. The compiler generates apps that are written in an interpreted layer and have been validated to some extent. The code is then executed JIT style with trust checks in the code. The real hardware is much akin to an MMUless 386.

You'd almost want to bootstrap the system with a JVM on the hardware and use the gcc compile into java byte code target to build your system.

I've heard the hardware can do it, but the software folks didn't want to give up cycles to indirection. Cray was all about maximum bandwidth, minimum latency. Hence, no cache, no virtual memory, shared libs, etc. The OS's job on a dinosaur supercomputer was to get the hell out of the way.

For a while, I had a Convex C1 in my living room, which was a vector supercomputer. If you wanted, you could run UNIX, complete with TCP and NFS on it, as well as Cray binaries. Assuming you had three-phase power and good A/C. I think my VAIO probably kicks its ass in every respect.

Or you could take all the insides out and use the chassis for rackmount equipment like a good stereo..

ps reports the tracing process as the parent, rather than reporting the original parent as the parent. AFAIK, ps gets its info from /proc, and you can verify that every occurrence of 'pptr' in the proc code is 'p_pptr' (referring to the parent) rather than p_opptr (referring to the original parent).

[The only times when p_pptr != p_opptr is when a PTRACE_ATTACH happened, or when CLONE_PTRACE was used.]

Although I'm the author of the patch, I don't think it's really the ultimate correct solution to the problem. The correct solution, IMHO, is (within userland) to always report the original parent in places where the parent is currently being reported. This preserves the illusion that ptracing isn't happening, for processes that don't care or need to know about it. For processes that really *do* need to know, there should be a "special" way of finding out--a new file in proc, maybe, or a new syscall or new ptrace subcommand.

Since the full "correct" solution isn't required for SUBTERFUGUE, and since I've heard that small, simple patches are easier to get into the kernel, I just used a minimal solution.

I think that illusion should be maintained, and really only debugging should know about the so-called "real" parent.

The whole "re-parenting" thing was just a bad excuse for not re-doing the parent pointers entirely, and should probably be ripped out at some point. We should probably

• get rid of "p_opptr"
• make "p_pptr" always be the real parent (which is not to say the process that does "fork()" - "clone()" can just clone the real parent field too, obviously)
• add a "p_debuggerptr" thing that is entirely new and ONLY used for debugging.

The reason for the re-parenting is obviously signal handling at exit time, but that's just such a special case that it's not really worth the confusion between "original parent" and "real parent". But it works, and this is code that nobody really likes to touch because it is so fundamental, so..

I talked to a genuine authentic (non-internet) lawyer about the GPL v BSD stuff a few years ago:

• GPL + BSD without advertising clause appears to be completely ok. Ditto the XFree86 one
• GPL + BSD with advertising clause is not compatible and the advertising clause is clearly an 'additional restriction'

In general GPL + anything is a no go unless the 'anything' is extremely non restrictive. The GPL draws an arbitary line and labels one side free they other not.

Since UC Berkeley dropped the advertising clause from their parts of the code its possible this problem has actually vanished by default in the kernel case now. I've not checked the documentation to figure this out.

There are numerous files that are under a dual license, which is perfectly ok. I don't actively encourage it, because it creates problems if somebody else than the original author were to ever say "I want to patch the Linux GPL'd version of this file, but I do NOT want to make my changes available under the BSD license" or vice versa, but it hasn't been a problem so far, so it's not something I discourage either.

(And besides, if somebody were to send me a patch with those kinds of restrictions, my solution would probably be to just not accept the patch in the first place).

The one file you mention (bsd_comp.c) is the only real special case that I'm aware of, which is why it cannot be linked into the kernel directly (it only ever gets built as a module - not for any technical reasons, but simply due to the copyright issue).

We're working on it. Andrea Arcangeli is currently improving the disk scheduling algorithm, I have some (small) changes to the memory management subsystem and a number of other people are working on patches that aren't ready/public yet...

It's true that we lag somewhat behind FreeBSD in this point, but we're working on it :)

I wouldn't call this cheating at all. There are a number of classical tradeoffs that you have to contend with when doing scheduler design. One is the tradeoff between efficiency and responsiveness. Switching between tasks costs, and so if you have a very heavily loaded batch system, it's most effiencient to set the scheduling quantuum very high, so that a process runs for long periods of time before some other process runs. On the other hand, for a desktop system, where user interaction is important, you want to set the scheduling quantuum as short as possible.

Linux does something similar, in terms rewarding processes that give up their timeslice before their scheduling quantuum is up, and giving less priority to CPU-bound processes. NT is simply taking it to the next level, and rewarding user-interaction more than other I/O bound processes. Since NT doesn't have an X server, they have to bump up the priority of the W32 subsystem when it's in the middle of doing graphics. The equivalent analogue for us on the Unix side is to run the X server at a slightly high priority. (Say, nice -4).

This isn't cheating; it's just making a policy statement that user interaction is more important that some of the other things that the machine might be doing. If a 10 minute kernel compile takes an extra 10 seconds to complete, it's not a big deal. But if mouse motion and keyboard response takes an extra 10 milliseconds, it is a very big deal as far as the user is concerned.