software:
prmscnet.el - networked Emacs Lisp code and data exchange
leaks.el - UNIX pipes leak into Emacs buffers
for notes please refer to promiscuOS_notes
1] Then, on February 5th, the author of bliss, apparently a nice guy concerned that an earlier alpha version of his code (which was posted on September 29, 1996 to comp.security.unix, alt.comp.virus and comp.os.linux.misc) could still be in use, posted version 0.4.0 to the widely read Usenet newsgroup comp.security.unix, complete with ample warnings and the prospect of a future (GPL'ed?) source code release.
Axel Boldt. Bliss, A Linux "virus." online 2000
2] ITS, in contrast, had a command whose specific function was crashing the system. All you had to do was type KILL SYSTEM, and the PDP-6 would grind to a halt. The idea was to take all the fun away from crashing the system by making it trivial to do that. On rare occasions, some loser would look at the available commands and say, "Wonder what KILL does?" and bring the system down, but by and large ITS proved that the best security was no security at all.
Steven Levy. Hackers. Penguin 1984
3] ... I judge computer security a disease rather than a cure, except for banks and such.
Richard Stallman. Computers Under Attack [Denning] 1990
PromiscuOS concerns non-functional artistic generation at socially-implied levels of code and production, favouring promiscuous, leaky code and data over security and division by function or task. The PromiscuOS project proposes the modification and re-distribution of an already existing GNU/Linux operating system with attendant functional applications. Such a modification will operate to remove security, segmentation and objectification (by way of category and filesystem) from all levels of the system (network and application) in favour of the generation, distribution and execution of mobile promiscuous code across all instances of the system. It is proposed that users would dual-boot such a system alongside the original (or close distribution), thus PromiscuOS offers a flip-side to the functional and divisive qualities of the original in favour of open promiscuity for the production of artistic computation. The PromiscuOS project engages with the open source development model of an existing operating system, rewriting core code of that system to divert towards the dysfunctional. At the same time PromiscuOS will be floated as a typical, though very well publicised open source project, attracting by way of Slashdot and the like a community of developers who can advance the system away from the divisive at kernel and application levels. The PromiscuOS project will offer all the usual trappings of such an effort, from mailing lists, through version control and both Sourceforge and Savannah repositories. PromiscuOS offers the exposure of an open source development model within the context of an artistic and supremely non-functional project.
PromiscuOS will exhibit the following characteristics amongst others.
a) Networked and environmentally active self display. Generation of code and data rather than response to input.
b) All process memory is readable and writable by any process or user. There is no hierarchy, no model of secure computing. Self display code will exploit this feature.
c) The ability to generate, disperse and run mobile code between machines.
d) Supreme pluggability - small apps can plug themselves together within a Unix model or a la Pd (but not in such graphic manner).
e) In relation to pluggability leaky streams rather than static segregated files - advance Unix model with new command line operations (spray, leak with level options specified).
The development model consists of publicity attracting community coders within a readily available infrastructure comprising content management, version control (of a fashionable variant such as darcs). The social nature of the project should be highlighted in relation to the crash event of February 11th 2004 curated by ap; both existing as discursive, social and code-based projects exploring highly production driven nature of operating systems within the expanded realm or economy of resource management.
notes:
removal of segmentation in networked and application layers [storage and execution] of an already ed memory management:
inserted notes:
1) working on crash issues/questions and perhaps towards promiscuous OS / promiscuous GNU/Linux project which features:
a) no access control b) promiscuous net I/O and attachment to all I/ in sbcl:
src/runtime/linux-os.c
which is one of files changed by Lazy-sbcl.diff:
from peter van eynd: http://pvaneynd.blogspot.com
"The patch is at the wrong place (linux-os.c) because there is no abstraction layer for 'get memory' and 'handle memory fault'."
notes 27 May 2005+
3) rather patch kernel so that: a) all pages are writeable and readable (how easy is this?) b) we choose a random page if a page is not available for whatever other reason
_____
3 June 2005+
self-display as essential - some sort of strace or gdb style stepping through kernel and application code required - how this could be automated achieved.
also look at old self[cpu] app which does self-display of processor registers
why it forks?
forks itself to make use of ptrace functionality to monitor registers
what level of self-display (level of abstraction of display) [ also brings to mind dual time/freq domain idea for cur/gdapp style app]
7 June 2005+
simply patching do_page_fault in arch/i386/mm/fault.c so does not send SIGSEV would work [test simply by handling SIGSEV in own code] but then would just repeatedly page fault - need allocate memory elsewhere within random process or all process memory is read/writeable by all processes in page table (and if is unallocated on page fault we allocate)
from tech_notes ::
The two opposing approaches:
1) Low-level modification (patching) of an existent operating system (GNU Linux, Hurd, other candidates?) or creation of x86-based
promiscuOS (virtualised a la Xen or not).
2) High-level sandboxed shared user-space a la ap0202 but as a (user-) space within which software can be compiled or interpreted and executed on a virtual machine layer which implies (an
intentionality of) leakage
...
Understanding the Linux Kernel (O'Reilly, Bovet et al.):
p376+
... the Linux Page Fault exception handler must distinguish exceptions caused by programming errors from those caused by a reference to a page that legitimately belongs to the process address space but simply hasn't been allocated yet.
do_page_fault() function (where? - arch/i386/mm/fault.c) is interrupt service routine for the 80x86 arch...
(from Linux Kernel Primer, PTR, Rodriguez et al:)
p238+
hardware interrupt 14 occurs when processor identifies the following conditions/exceptions:
(note exceptions can be classified as faults: the EIP is the address of the instruction that caused the fault - hence allowing instruction to be resumed if the condition is corrected. and if not...)
and from p183+
we find that the page tables are provided by OS to the MMU (Memory Management Unit - note lacking in sat Motorola 68000 and thus uCLinux port) to enable translation between virtual and physical addresses and to allow paging. (thus phys=virtual under uCLinux) - hardware promiscuity is perhaps promoted by this lack of abstraction, this bare equivalence.
3 bit error code is pushed on the stack by control unit when exception occurred:
do_page_fault is charged with handling possible scenarios, first up reads linear address that caused page fault.
mm_struct descriptor is for process memory
bad_area
jump to label bad_area if (what we're interested in) task's memory region does not include the address or address is not in current task's address space
thence:
is it in user_mode -> SIGSEGV
no - then jump to no_context:
if there is not an entry in the exception table for the offending instruction, we end up with oops screen dump
thus:
for promiscuOS, sharing process memory could be achieved at the level of hardware (uCLinux inspired), process memory creation (allocation) or some kind of patch to the page_fault handler (??)
Creating a Process Adress (p392+ O'Reilly)
clone, fork, shared memory space, parent space, COW...
from promiscuOS below::
All process memory is (un)intentionally readable and writable by any process or user.
2006 - promiscuOS - twins of low level kernel stuff and higher level pluggability - contradictory directions sans sandboxing - but could also think of Xen
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
a) Networked and environmentally active self display. Generation of code and data rather than response to input.
b) All process memory is readable and writable by any process or user. There is no hierarchy, no model of secure computing. Self display code will exploit this feature.
c) The ability to generate, disperse and run mobile code between machines.
d) Supreme pluggability - small apps can plug themselves together within a Unix model or a la Pd (but not in such graphic manner).
e) In relation to pluggability leaky streams rather than static segregated files - advance Unix model with new command line operations (spray, leak with level options specified).
http://galinha.ucpel.tche.br/coop?page=Connecting%20to%20a%20REPL%20via%20sockets
(defmacro pd-speak (body) `(system (concatenate 'string "sendOSC -notypetags -h 127.0.0.1 9999 \"/test, " ,@body " \"")))Gambit-C particularly under examples/distr-comp for promiscuOS
from README:
This example is a distributed application composed of two nodes
(running in the same Scheme process). A thread is started on the
first node. The thread performs a loop. At each iteration of the
loop it prints the name of the node it is running on, then the thread
migrates to the other node. This example can easily be changed so
that each node is running on a different machine. Say the machines
are "foo.com" and "bar.com". The machine "foo.com" should run
(define (main)
(become-tcp-node
9000 ; TCP port-number for this node
'foo ; name of the first node
(lambda () 'no-op)))
An the machine "bar.com" should run
(define (main)
(become-tcp-node
9000 ; TCP port-number for this node
'bar ; name of the second node
(lambda ()
; start a thread on bar.com
(spawn
(let ((n1 (current-node))
(n2 (make-tcp-node "foo.com" 9000 'foo)))
(let loop ((i 0) (a n1) (b n2))
(if (= i 100)
(exit)
(begin
(if #t
(begin
(pp (list i 'from (current-node-name))
(current-output-port))
(force-output (current-output-port))
(thread-sleep! .1)))
(goto b)
(loop (+ i 1) b a)))))))))
we can begin to specify components for promiscuOS ::
0) all ports, files open. all environment data collecting. all sniffing 1) jackd and all such connectivity including piping/OSC command line tools and other such tools 2) pipe dribblers, jack dribblers, containers, spillage 3) total remote execution environment as above or with Simple Grid Protocol http://lemonodor.com/archives/001105.html or some inetd methodology 4) patches based on sbcl segfault stuff for kernel. leaks installed 5) generation of GA-style code for remote and local execution - environment-based a la ap0202 6) specify self-display? 7) local and remote arbitrary/leaked or container (bucket) exchange of data (again a la ap0202) further components:
leakage is implied by sniffer functionality (for example OSC conversion ones below from gulli people). further leakage of OSC and jack itself could be coded. pipes also by way of kernel patch - where is pipe code in kernel?
/usr/src/linux/fs/pipe.c
what would determine moment of leakage - some trigger in the data itself matched across a changing sequence - a neuron or series of connected neurons which sniff the data and trigger/balance leakage -