[cap-talk] Designation linux kernel patch concept

[Richard Uhtenwoldt]

I am using an unfamiliar mail client, so apologies for any format
infelicities.

On 11/30/07, Rob Meijer <capibara at xs4all.nl> wrote:
>
> I have been giving some thougth about the posibilities of a designation
> patch for the linux kernel,
>
> Before I start trying to implement it, I thougth I would run it
> by you guys to see if I am on the right track here.
> My linux kernel development experience is very small, so I could be
> overlooking some important stuff here.


Although it would be a great victory for our cause (of spreading
our ideas and thereby facilitating cooperation without
vulnerability) because there are so many participants in the
linux ecosystem, the probability of success is very low.

I know of a few kernel patches over the years including one by
very skilled programmer Ron Minnich (a Plan 9er) and none of them
lasted for more than a year or two.

What happens is that they successfully patch the kernel, but then
they have to maintain it: i.e., you have to modify it to reflect
changes in the rest of the kernel, and the Linux kernel gets
remodeled constantly (like living bone gets remodeled
constantly).  It is the cost (in programmer time and attention)
of keeping up with the changes in the kernel (and perhaps other
softwares, like the C library strongly integrated into the kernel)
that causes the majority of kernel patches to have very short lives.

To reduce this cost, you have to convince other kernel hackers,
influential ones, of the worthwhileness of your patch.  Otherwise
they go about their work as if your patch does not exist.

But I strongly advise against patching the kernel.  the kernel is
the most difficult part of Linux-broadly-defined in which to
introduce a change.  This fact has almost nothing to do with
source code, data structures or any other technical concern but
rather with the fact that the influential linux hackers are
conservative and some are quite opinionated.

I tend to believe that there is a significant probability that if
enough effort is applied by enough people, object capability
principles can be insinuated into the lives of the majority of
participants in the linux ecosystem.

Here is how I would do it.

The kernel is sexy (and the VFS is a sexy part of the kernel)
and sex attracts cooks and too many cooks stomp all over your
patch like arrogant knights stomping the crops of the powerless
peasant farmer.

The thing to do is introduce changes to a place that most
decisionmakers in the open-source ecosystem consider drugery.
Packaging.  System administration.

There are millions of linux system administrators because a large
fraction of linux users (desktop-Linux users) spend a lot of time
adminning their system, which by definition makes them (unpaid)
system administrators.  One of the big weaknesses of Linux
compared to other choices -- especially OS X -- the fact that the
frequency and severity of admin hassles is higher with Linux.
Some software got upgraded and now the OS will not boot.  You
tried to customize your system, but the customization had the
unintential side effects and you cannot remember how to get back
revert the customization.

What follows is very compressed.  I am going to give hints and
rely on the reader to grasp the gestalt from just one or two
pieces.

Now I will introduce what at first seems unimportant and unrelated:

Over the last ten years the linux community has reach a consensus
that the choice of where in the file name space a package of
software installs should not be decided by the maintainers
(programmers) of the software but rather by the admin.
How the admin usually does that is to give ./configure the flag
--prefix=/usr/fred/.

With some sharply defined exceptions like /etc, that flag causes
every executable in the package that reads or writes (or ...) to
another file "owned" by the same package to look for the file
in /usr/fred rather than in a place hardcoded by the author of
the software.

By "community has reached a consensus" I mean the following.

A large distribution like Ubuntu offers the admin a selection of
about 30,000 packages (the vast vast majority of which are open
source).  For all practical purposes, all 30,000 packages let the
admin decide where the software will install.  This is almost a
complete change from 15 years ago.

Consider for a moment how you would have achieved that.  Does
your answer involve POLA, unforgeable references or pointers to
opaque objects, guards, type checking, cryptography, AppArmor?

It was achieved by a social process with only very very simple
technical content.  Specifically, a maintainer of a sofware that
did not conform to this policy changed his software because he
knew if he did not it would eventually be dropped from
distributions and eschewed by admins.  The community will
consider the software to have a bug which the maintainer refuses
to fix.

For the sake of brevity, I conflated above the role of "package
maintainer" or "software packager" with the role of sysadmin.

This change or new regularity in the linux ecosystem I just
described is not very technically interesting: it does not to my
knowledge make the OS more resistant to attack or even reduce
admin hassles all that much.

The technical challenge for those who wish to insinuate
object-cap ideas into mainstream linux is to introduce another
regularity of a similar nature.

I am relying heavily on the reader here to imagine the technical
specifics of what that regularity might consist of.

To a first approximation, a change either spreads to almost all
linux users  or it remains very marginal with 100 users on a good
day with a large chance of eventually disappearing.

When and only when there is ample evidence that change #1 is well
on its way to becoming universally adopted in the linux world do
you contemplate any change that relies on change #1.

Contrast that with the usual method: the programmer creates a
plan or design in which hundreds of interdependent changes or
elements are introduced at once.  Microsoft can still do things
that way.  You and I cannot.

Note that a sufficiently energetic programmer can profitably
introduce simultaneously hundreds of changes to Linux: they just
cannot be interdependent changes.

Note also that this is not the way I work with software, but
then I am the only user of the software I write.

Of course there are many exceptions to that principle, but the
principle holds for a large fraction of the most interesting
possible changes and for all of the changes I remember seeing
people on this list propose.

In summary, to change an open-source software with a large number
of participants, you must spend more time paying attention to the
opinions and beliefs and habits and self-interest of the
participants and how they might affect the chances of a change
becoming nearly universal than you spend on planning or designing
in the traditional sense.

Again, if I were to embark on such a project, I would sell
my idea to admins and package maintainers, not kernel hackers.

And I would not claim that the idea will increase security or
make the computer more resistant to attackers (even if it does do
those things), because most decisionmakers have no way to
evaluate security claims.  I would claim to reduce admin hassles
because that is a claim an admin can verify decisively (by doing
what admins like best: adminning the system).

I have many more thought about introducing cap ideas into the linux
world.

I will look for replies for a couple of weeks but then I plan to
unsub from this mailing list, so if you are reading this after
2007 Dec 17 or so you will want to email me to get my attention.

My main email is ru at sonic.net.

Richard Uhtenwoldt
-- 
Text by me above is hereby placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20071202/41ec8ee2/attachment.html