[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux-NG


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 GIMP, fully usable for image manipulation as a
text-based command.

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


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

Reply to: