Re: Linux-NG

[Francis Whittle <fudje@subdimension.com>]

Hi,

> 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.

---snip---
> Imagine GIMP, fully usable for image manipulation as a
> text-based command.

Whaddya' mean imagine?  You can already.  Well perhaps not fully, but 
still...

---snip---

I just don't see a detached UI like that cathcing on.  Perhaps if there 
were some
library to link to that could have like a Pass-thru API to another 
library,
configurable (which could be an interface to a toolkit lib, et c.), 
that becomes
more pheasable, but I think one of the major aspects that drives the 
Free Software
Community is that element of choice.
I definitely don't see command-line scripting and exported cores like 
that catching
on.  I mean, using interpreted languages is slow enough, let alone 
exporting the
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 
> 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?

Kinda' like nfs tunneled thorugh ssh, but for individual users (Of 
course there
are other flaws in nfs), and then remote execution over the top of that 
as well?
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 
need a
heap of security on your connection for that kind of remote execution.  
This
isn't too hard to acheive already, too (ssh tunnelling, et c. SSH in 
particular
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 
> 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.

This is a nice idea indeed, but for the truly paranoid you'd need to be 
able
to guarantee that the hardware was not accessible.  This would also, in 
effect,
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 
processor no
memory channels required, and _that_ would require an amount of 
processor and
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' 
strongest strength
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 
only
accessible through a two-way pipe that only accepts limit input and 
gives precision
output, and could also run a parrallel 'auth init'.  Furthermore, a 
hard disk
partition could also be reserved for this parallel kernel, that is in a 
specific
hash format (And is, obviously, resizable), so that the password hash 
is stored
off-disk.  If you want to go totally troppo, this could also use an 
authenticated
key-pair system (for transport only) to allow a defined secure network 
authentication
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 
may be
configured to only allow authenticated users of the system (who do not 
necessarily
have super-user access) to boot using these methods -- allowing minimal 
compromise
with distributing root passwords and so-forth.  Of course, the 
filesystem security
methods would have to be updated a little, but what's that compared to 
all this?


Enough brainsplatter.
Share your thoughts.

Francis Whittle
(fudje)