Linux-NG
[Hello to the debian-devel list. I thought you might like to see this,
too. I just submitted it to debian planet, but I thought you might
like to see it as well. It's cc'd to Debian Planet, to prevent replying
going to them without some extra effort.]
OK. "Linux"-ng is a little overstated. How about just Debian-ng for
now, and let the others play catchup? This article is the culmination
of some thoughts brewing inside my mind for the last couple of years,
which I think could give us a very extensible and usable environment
above and beyond the environment we all enjoy.
The impetus for this writing is the recent slashdot article on Microsoft's
"Next Generation" shell. It looks like something that we, the Linux
community, could easily reach, and reach quickly. And we could go, with
the software, knowledge, and workers available, far beyond this. This
idea involves several different pieces.
The first piece involves command-line scripting, which was the aim of
the article. It would be very nice if *every program* exported the
core of the program and functionality as a set of shared libraries,
java class files, etc. and left the user interface to the executable
itself. What would this accomplish?
First off, it would allow third parties to create new interfaces to it.
Imagine openoffice as a text-mode program (yes, it seems kind of
silly, since it'd no longer be wysiwyg, but one could have the interface
edit the fields and underlying codes, such as changing font size or
margins). Imagine GIMP, fully usable for image manipulation as a text-
based command. Imagine openoffice "skinned" for KDE, so that it is
fully integrated with KDE.
It would also allow, with some object-orientedness, the command-line to
do certain things, such as open an MS Office file (e.g.
linkin openoffice-core-lib-1.2.1.so oocore
file=oocore.openfile("/home/user/somefile.xls")
oocore.savefile($file, oocore.formats.openoffice-1.0.1)
ulink oocore
) and save it as an Open Office file. I'm sure we could think of
lots of other nifty uses of this. Just use your imagination!
Secondly, we could extend this to remote systems. Either via things such
as a user-space filesystem (I can't seem to find information on it right
now. I either saw it in Linux Journal or Linux Magazine within the last
couple of months), which allows people to mount such odd things as
ssh-based "filesystems", or as additional shell abilities to connect
remotely and transfer data, such as, say, an xml-rpc-based tool:
xml-rpc://someplace.com/xml-rpc/exec-something < file > otherfile
or
linkin xml-rpc://someplace.com/xml-rpc/somelib.1.2.3.so someplace
square=someplace.square(32)
ulink someplace
Maybe this could be done via a systemwide wrapper or lib that recognizes
protocols that the shell then hands off the work to?
Thirdly, we need to examine remote connections and security. We need it
to be as easy to the user to run something locally as it is to run it
on another system, but we also need to make sure that the system is
*secure*! We need to look at transparent user credential exchange and
authentication systems, and possibly re-engineer our security systems
to use these.
Finally (for now), we need to increase system security. The crypto stuff
in the kernel is definitely a step in the right direction. But we should
give the admin a way to shut down all access to the kernel via kmem and
such, and then possibly make modules and programs signed. IDS works great,
but it is after the fact! We need to augment IDS with IPS (prevention),
and digital signatures is a good step towards it. I know there are several
projects in the pipe for next-generation apt that apparently will improve
system upgrade security, but we also should have the kernel look at
programs and modules and optionally reject bad signatures and no signatures.
This will probably require integration into filesystems, so that we can
keep track of signatures, such as filename:signature or so forth. Note
that this might have security implications itself.
With the kernel untaintable (in theory and excepting vulnerabilities), the
users info could be associated with them in the kernel, and available in
each process's information. Hrmm. Maybe not in each process. But the
kernel could act as a known-trustable source and provide cryptographic
services to the user without relying on potentially corrupted files.
Note that the data would not necessarily be signed, and the admin gets the
option of preventing unsigned files from being run, so we're not going
down the Pd road. Especially with this crowd, I doubt that that would
be a problem. :)
Eventually, it'd be nice if the kernel interacted with hardware (being
paranoid all the time!) so that user credentials never get stored in
memory, nor reside anywhere directly (except in the piece of hardware),
nor get transmitted anywhere, so that even the kernel has zero knowledge
of the user's creds. But that requires hardware firms to work with us,
so that may be a ways off.
Sound good?
--
Joseph===============================================trelane@digitasaru.net
"I use Linux and it makes me feel safer knowing exactly what security
problems my boxen are facing. If I wanted filtered information or a public
relations a** kissing, I'd use Microsoft products." --dattaway, on /.
Reply to: