[Savannah-hackers] [ 100653 ] What SSE should do

[nobody]

Support Request #100653, was updated on 2002-Mar-26 12:11
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=100653&group_id=11

Category: None
Status: Closed
Priority: 5
Summary: What SSE should do

By: yeupou
Date: 2002-Mar-26 13:08

Message:
Logged In: YES 
user_id=1896
Browser: Mozilla/5.0 Galeon/1.2.0 (X11 ; GNU / Linux 2.4.17 i686 ; fr_FR)

I'm sorry but I dont understand the connection between what
you are talking about and the savannah project.

This forum is only about the savannah project, not about
each project hosted by savannah.
Sorry.

Discuss about this to the proper mailing-list or forum.

----------------------------------------------------------------------

By: grrp
Date: 2002-Mar-26 12:11

Message:
Logged In: NO 
Browser: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98; AxtelNet2)

Hello,

I've read almost all the gnudotnet, and pnet websites. 
All that sounds great. I have ideas, and I'm not sure 
if they are suitable, so, think of it as a brain-
storm. I am not a security consultant, so, read rather 
sceptically, but may be... Well, to the point.

I think of the SSE as the main daemon that should be 
(almost) the same on servers and clients, so you can 
execute the same code into both boxes. As a secure 
space, it must restrict the potential damages to the 
system and user areas. The system can be "easily" 
protected, but the user areas are more exposed, 
because the programs sometimes should "touch" the user 
data, to handle it.

I have already a secure box embeeded into my insecure 
windows. This secure box is a macintosh emulator. It 
provides a hardware emulation (wow!), including:
- Memory space
- Disk space
- CPU cycles & architecture
- ROM and other stuff
- Network interface (it really does not provide this, 
but think of it as if it were)
- etc. (think here any virtual device you want)

You got it. This approach is simpler, maybe slow, 
memory-consuming and has the inherent problems of 
emulators. But effective, programs surely will never 
have access to my windows files, other than the 
assigned loopback-device file. We can think on how to 
merge advantages of an emulator and a daemon, on how 
to provide a mini-kernel-with-plugins to our secure 
box, and so on.

Ok, for now, forget the emulator idea, and go on with 
more important things about SSE. The implementation, 
must contain, from my point of view:

- Its own file-system for protecting the system and 
user data (only for data). This implementation must 
discard sysadmin intervention, because the vast 
majority of home users -rather home sysadmins- doesn't 
care about it. This may be a (variable-size) loopback 
device. It would be possible to let the user restrict 
or grant access to his files to a program. If the user 
had deny access to his files, the daemon should 
provide an empty loopback disk space to the app, so 
the app should still work, but without seeing any 
existing file, and still can write something. The user 
should be able to copy files from his main space to 
the new loopback space, in order to let him modify 
some files using (or testing) the app. That would be 
totally safe. Each user (including the system-assigned 
user) could have its own loopback device. That way, 
replication could use some kind of raid-arrays 
algorithm.

- A memory manager, that: create a unique space for 
each process. That should be limited by a safe maximum.

- SSE may run its own authentication engine. This way, 
accounts data (user name, password, etc.) should be in 
the system special space (memory and disk), totally 
unaccesible from a user program or any plugin. That 
way, it should be nearly impossible to miss a 
configuration. "Do not hire a cop for giving 
permissions, assign it yourself". Otherwise, how will 
authenticate the security plugin itself? This engine 
should forbid by default any inter-process 
comunication for client-processes having diffent 
access levels.

- Each never-executed program should automatically 
obtain a new user account, that contains the username, 
for logging purposes. You will figure out more closely 
what happened in that failed attack :)

- The network interfaces should be limitable by the 
daemon, and it should take some precautions about 
attacking. Any communication should be encrypted, 
avoiding network sniffings.

- All the underlying bytecode plugins should execute 
their processes passing all the system calls through 
the SSE daemon, allowing it to: 1) create 
disk/memory/process spaces on-demand, 2) autenticate 
actions, 3) limit resources, 4) log, 5) integrate 
configurations. An example of the configuration 
integration should be: The client code request a new 
object of class "fooclass", but it does not know at 
which machine it is hosted. The daemon knows that it 
is located in the "abc.foo.com", and it will pass the 
encrypted request to "abc.foo.com", providing the user 
autentication data. All that will be transparent to 
the application, but more interesting, will be 
transparent to the bytecode engines.

Special care should be taken with the last point. 
Without concentrating system calls in the SSE daemon, 
will cause that the bytecode engines have to do each 
check itself using libs, or to pass calls to the 
indicated plugin, in order to address disk/filesystem, 
memory, network, process and/or auth operations. Then, 
for what is the Security Environment? Other unwanted 
side effects if you don't keep together that things 
would be: 1) you couldn't be able to modify security 
issues easily, and 2) in case you do, you had not be 
able to distribute the SSE independently of the other 
gnudotnet components (something like this happens with 
gnome or kde: I can't install only the new core 
components, and stay running successfully the apps. I 
have to download all the daemons, libraries and apps 
together, because very often the components become 
incompatible between them).

Apps should be that: apps. VMs should be only bytecode 
interpreters, not other. And the security layer should 
control ALL security issues, centralized in one place.

My ideas sounds like a new operating system, but it 
isn't. I think of it only as a portable 
framework/server that will provide safety to a running 
and existing environment.



Well, sorry, very much if all that was boring, but I'm 
very interested in the project, and think I cannot 
write such an advanced code (yet :-)

Regards,



----------------------------------------------------------------------
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=100653&group_id=11