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


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

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?

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