Rockwall Linux

Note: Rockwall is only a codename, the final distribution will most likely be called something else.

Focus

• Ease of Use
• Security
• Flexibility
• Stability

About

The goal of Rockwall is to make a hardened Linux distribution that makes it easy
to use the security, while being flexible enough to allow you to get work done.
It is designed, from the ground up, with the enterprise user in mind.

It has been my experience, as someone who supports users, that most users do
not have a clear idea of why certain actions are dangerous to their security.
I’ve also seen that, because of this, that they end up getting the brunt of the
blame for being ignorant to the dangers that surround them in an increasingly
networked world. At the same time, I realize that they don’t necessarily have
the time or resources to educate themselves while still trying to get the jobs
they have been paid for completed.

My other observation has shown me that systems who cater to these people
typically forget about the people who have to support them. They simplify
everything down for them, and strip out the tools with the real power that
support professionals need in order to fix things quickly when something
breaks down.

The idea behind Rockwall is to create a Linux-based distribution aimed at the
desktop user, that integrates well with the server, and yet still retains the
flexibility desired by the power user.

User Interface

One of the first things that I looked at, when thinking of how computers are
used in the enterprise, is the user interface. Most enterprise users are going
to be using a graphical based interface it, let’s face it, most are going to
be using Windows 7. In order to make my system palatable, I need to keep this in
mind. Personally, I prefer Openbox. I realize that would be a horrible choice
for the enterprise user. I figure, if my mom can’t use it, most of the people
I support can’t either.

I looked into the popular choices for mainstream distributions, and they use
either Gnome 3, KDE 4, or Unity. I also looked at the enterprise offerings,
which tend to be much slower on the updates, and they tend to use legacy
versions of Gnome 2. I feel all these choices are bad for a couple of reasons.
I’ll break them down individually for you.

Gnome 2: No longer supported by the upstream vendor. Sorry, for me, that’s a
non-starter when designing something for long-term use. That’s why this gets
the shortest paragraph.

Gnome 3: Has a few glitches that really annoy me. One major example is anything
that needs to be full screen. Flash for example, commonly used for things like
instructional videos on corporate websites, can flake out unless you go in
and run something like devilspie, which would be fine if the fixes were
consistent. It’s that inconsistency that really keeps me from using it at an
option. That, and its default user interface seems out of place in a Windows
start menu based environment. Yes, the start menu, simple, but extremely
important for usability on the desktop.

KDE 4: Integration for this offering is key. The problem arises when you try
to integrate with non-qt based apps. To be fair, this can be an issue for
Gnome 3 with non-GTK based apps as well, but it hasn’t been as apparent in my
personal experience as with KDE. This may be due to the fact that more apps are
GTK-based than QT-based, although I do see the tides turning on this issue.
Maybe in the future when more developers adopt QT as a base toolkit, one that
I personally find superior than GTK in my very biased opinion, then maybe I’ll
reconsider it. Until such a time, I will have to politely decline on KDE.

Unity: See Gnome 3. Unity seems to have all the drawbacks of Gnome 3, and they
also adopted the MacOS placement of close buttons on windows. If you’re
migrating from a Mac environment, I can see this as a viable option, otherwise
I’m stuck with a no. Retraining muscle memory is painfully difficult. I don’t
want to change an elementary component that 90% market share is used to using
differently already.

What I chose? I chose to go with Cinnamon. It gives me all the really nice parts
that I like about Gnome 3 and, so far, none of the drawbacks. Full screen
applications don’t seem to have that glitchy flair present in Gnome 3, and the
user interface is one that is immediately identifiable with former Windows users
which make up the bulk of my target audience.

Security

As a security analyst, it’s my job to think about security. I’ve been looking
at the various security offerings for Linux, and have come to several
conclusions. My general consensus is that most security enhancements come in two
flavors: easy to use but inadequate, or complete solutions that are so complex that
nobody will ever use them.

This has to change, but I don’t want to make an entirely new security system,
that’s overkill. My idea instead was to take the best of the current offerings
and augment them with tools to simplify their usage. This aspect of the project
is very much a work in progress. To start, I’m starting with filesystem and
kernel security enhancements.

I don’t want to use AppArmor, due to the fact that it uses absolute file paths
for security. This is just retarded and can be circumvented with a symlink on
some filesystems. Also, the subprocess security is a joke in that it makes it
relatively trivial to inject something into a subprocess to infect the parent
process and achieve an escalation of privileges according to my research.
This is why I will be using SELinux and its inode approach. For those of you
who are less tech savvy, an inode is the actual file object on the disk, not
the abstraction you see when using your favorite filesystem browser. This makes
inodes inherently more secure, because even when you move a file – or create
a symbolic link (symlink) to one, its inode remains the same, so it retains
its security settings.

The problem I found is that neither AppArmor, nor SELinux do enough in regards
to kernel security. This is why I decided to combine them with the
Grsecurity kernel patches. Grsecurity is often touted as a good alternative
to AppArmor and SELinux, although in truth, on its own, it’s a horrible
alternative. It doesn’t do enough in the file space. But what it does in
kernel space is wonderful, and it plays nice as an extension to either
AppArmor or SELinux, so why not take advantage of it and use it shim the
areas where AppArmor and SELinux both, admittedly, lack and protect the kernel
space with it. Grsecurity will prevent unauthorized execution of code via
injection into otherwise authorized executions, and SELinux will be used to
protect confidentiality of data.

The problem with both SELinux and Grsecurity is the availability of easy to use
tools. The tools it provides are full featured and very powerful, but all except
the most knowledgeable are unable to use them effectively. I don’t want to remove
any of this power, but I’d like to make it easier to at least maintain best
practices for those of us who are not elite hackers who know everything there
is to know about Linux security. That is not to say that those people should
necessarily be in charge of security, but rather to encourage the home user
to make use of the protections created by these tools, as well as increase the
efficiency of the CSO/CISO by presenting the features in a more intuitive manner.
I will, of course, keep the default tool stack available, and merely build on
top of it an interface that simplifies common tasks. In this way, I make it
easier to be secure, while still retaining the raw power of the foundation
tools themselves.

More

I’m still in the early planning stages of this build, so there is a lot more
going on that I didn’t mention in this post. Please do stay tuned, and I will
keep you all updated as this project moves forward. I would also invite any
opinions, advice, or criticisms that you would care to offer as I work out a
plan of attack for actually implementing my ideas. I am not actively seeking
volunteers at this stage of development, as there really isn’t enough done
yet to make a cohesive plan, but any and all contributions will be welcome,
whether they get used or not. Thank you so much for reading this article and
not just looking at it and saying TL;DR. I appreciate the interest, and it’s
interested parties like you that drive me to continue pushing forward in spite
of the difficulties the task presents!