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
Imagine GIMP, fully usable for image manipulation as a
Whaddya' mean imagine? You can already. Well perhaps not fully, but
I just don't see a detached UI like that cathcing on. Perhaps if there
library to link to that could have like a Pass-thru API to another
configurable (which could be an interface to a toolkit lib, et c.),
more pheasable, but I think one of the major aspects that drives the
Community is that element of choice.
I definitely don't see command-line scripting and exported cores like
on. I mean, using interpreted languages is slow enough, let alone
core to the calling process in order to run it.
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
right now. I either saw it in Linux Journal or Linux Magazine within
last couple of months), which allows people to mount such odd things
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
Maybe this could be done via a systemwide wrapper or lib that
recognizes protocols that the shell then hands off the work to?
Kinda' like nfs tunneled thorugh ssh, but for individual users (Of
are other flaws in nfs), and then remote execution over the top of that
Sounds Interesting. Dangerous, difficult, but interesting.
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.
I can see this tying in a lot with your "Secondly". You'd definitely
heap of security on your connection for that kind of remote execution.
isn't too hard to acheive already, too (ssh tunnelling, et c. SSH in
has a good keys-based system).
Finally (for now), we need to increase system security.
--- snip snip snip ---
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
nor get transmitted anywhere, so that even the kernel has zero
of the user's creds. But that requires hardware firms to work with
so that may be a ways off.
This is a nice idea indeed, but for the truly paranoid you'd need to be
to guarantee that the hardware was not accessible. This would also, in
require kernel hooks to be extended waaaay into user-space, such that an
authentication system could simply tell the kernel (perhaps using a
module of some
description) to open a device for a direct pipe, straight through the
memory channels required, and _that_ would require an amount of
channel re-engineering. This would be a bit like turning Linux into a
sort of MVS
and then beyond a few strides, whilst still being Linux, and it would
only work on
systems that are a lot like toned-down mainframes. Still, Linux'
is its modular versatility.
I could suggest that a more credible (and somewhat more attainable)
solution would be
to run in the Linux VM a parallel-process kernel that reserves a
specific area of
memory for this very purpose. This would require a threading system in
the host VM,
but it could be defined like a device in the Linux kernel. It would be
accessible through a two-way pipe that only accepts limit input and
output, and could also run a parrallel 'auth init'. Furthermore, a
partition could also be reserved for this parallel kernel, that is in a
hash format (And is, obviously, resizable), so that the password hash
off-disk. If you want to go totally troppo, this could also use an
key-pair system (for transport only) to allow a defined secure network
system. This system could also define secure pre-boot authentication
so that system
recovery methods that may otherwise form a security flaw in the system
configured to only allow authenticated users of the system (who do not
have super-user access) to boot using these methods -- allowing minimal
with distributing root passwords and so-forth. Of course, the
methods would have to be updated a little, but what's that compared to
Share your thoughts.
- From: Joseph Pingenot <firstname.lastname@example.org>