Anyone heard of SSOOS?

[Hextic]

Just an OS I am working on, if there is any interest I will take the five seconds to post a link to the project web page.

[Staticwave]

Never heard of it but I like to see what fellow posters are working on. Post a link or send it via PM please. I'd love to take a look.

[Voltage Spike]

How about this link?

[Hextic]

How about this link?

Wow, I am allready on the top of google?

[Hextic]

Sorry about the double post, but I would like to put it out there that I am going to be releaseing a full copy of the plan so far, so that I can know if I am digging myself into a hole by making some form of mistake, and if I am, to correct it. One brain can do great things, but many can do exponentially greater things.

[Staticwave]

How about this link?

Hey, he offered to post the link... Why dig through the trash when someones willing to hand you what your looking for?

[Voltage Spike]

Hey, he offered to post the link... Why dig through the trash when someones willing to hand you what your looking for?

I was pointing out that it was faster to find the link myself rather than wait for a response. Oh, and I didn't "dig through the trash"; as Hextic pointed out, his project is the number one and two ranked links.

As the project, the application ID concept is interesting. However, what are you hoping to advance over, say, IBM's support of the Trusted Computing Platform Alliance under Linux? The really cool (although there are problems) part is the limited file access based on the application. I'm sure someone has done this before, but it seems like such a system would greatly limit the viability of malicious software.

[Hextic]

Thanks for the input. =)

There is one part that I am reluctant to put there, because I am not sure of it's usefulness. Ever heard of those programs where you select a password text field, and it grabs the contents out of memory? I am thinking of a system call for storing and manipulating small-ish amounts of data inside the kernel's protected memory. This could be slow, and programming all the things you can do to a variable would make for an overly complex system call. I am not sure if the trade-off is worth it. To access it, you have to make a call, and only an application with the PID of the application that reserved the space can access or even read it. I am also afraid of people treating it as a silver-bullet and ignoring other important security issues, such as buffer overflow conditions. Things that could be stored in this way and be immune to unwanted reads:
password box contents
sensitive counters
etc.

[Voltage Spike]

There is one part that I am reluctant to put there, because I am not sure of it's usefulness. Ever heard of those programs where you select a password text field, and it grabs the contents out of memory? I am thinking of a system call for storing and manipulating small-ish amounts of data inside the kernel's protected memory.

Mac OS X's Keychain works much the same way. It is kind of nifty in that it notifies the user of which application is trying to get to a key, which key, and gives them the standard options ("Deny", "Allow", "Always Allow").

You may also wish to look into the implementation of the user-space ssh-agent. However, ssh uses assymetric keys so you never transmit the secret information, and I think it assumes some level of trust at the end-user's computer.

You are already limiting file access based on application ID; what is the point of adding a system call that does the same thing? The only reason I can come up with is that you wish to have a centralized, encrypted keystore without encrypting the entire system.

PS: This discussion is now number 2 in Google's search results ... sorry.

[Hextic]

It is not files that the kernel space is protecing, but stack data. If a user is typing a password and another program is watching the memory offset that the passwordbox's contents are stored in, game over. If it cannot, then that is one more form of attack prevented.