OSDev.org

I've had a somewhat strange idea regarding security. Why not allow programmable security features by giving processes and files a possible "slot" in their exported function tables or in file attributes to appoint a bit of code that will evaluate the given parameters to determine proper permissions? For example, I'm planning on doing this under Reiser4 filesystem, so a sub-file of a file with a given name could be a small program responsible for checking security beyond normal file permissions. To get access to the normal file or the security file you would either have to be root or it would have to return a code allowing you access. The same principle could be applied to processes and libraries (at least under my OS design) by giving them a security function. If it's present, it must evaluate to say... "true" or an integer > 0 in order for anyone but the administrator to access the process/library.

This sort of thing would make security far more flexible. Perhaps the security function or file could even override normal permissions where present, allowing or forbidding a user who actually had regular read/write/execute privileges.

The security file/function itself might even be given full guaranteed access to the process/file (since we can presume that either the owner or the person who created the file/process put it there, we can ask them to vouch for the security of the security file/function), so that rather than needing privileges to access a file you might need a password or other authentication, which would let the security file or process decrypt data to make the file/process work, and even then you might have limited access to a sensitive file like for example /etc/passwd.

Unfortunately, this sort of thing could be used for DRM also... No, wait, as long as the superuser has guaranteed full access to every file (and they usually do), the DRM would only work on normal users. Those who got help from the admin could bypass any DRM scheme based on this idea.

As good as the idea is, it's probably going to be used mainly by some geeks, loads of crackers (and thus scriptkiddies who use their programs) and loads of companies trying to bully you into paying them an amount per millisecond of use.

What's your target user base and does it add anything they need?

My target base is me and any other hacker who wants to touch the thing.

Yes, it adds something that some people need, which is the ability to 1. Put tighter security on certain special files or 2. Make files "react" to their being opened.

Osmium OS:

Devices will be accessible as files. Advanced drivers will be run in user-space while basic core drivers(floppy,keyboard, and the text console) will be compiled into the kernel.

Inter-process communication would be done with a SendMessage function which takes a message for a process and stores it in a global list. When a process wants to receive messages it calls GetMessages which returns a linked list of the applications messages.

Applications will be able to be started in two modes: applications and library. So app A can use app B's shared commands.

Any suggestions are welcome.

At this point a discussion on IPC, PIC and a couple of other topics ensued which I took the liberty to split into a thread of its own - see Osmium, IPC, PIC and the rest.

My OS (no name yet):

Well, my design ideas have changed dramatically since my last post here. First of all, I have decided to have everything accessible as an object. That is: proccesses, drivers, other computers, everything. All objects are going to be stored in a kind of tree, where each node contains a pointer to two other nodes, a son and a brother. In this way the tree is more like a lot of circularly linked lists where each node can link to another list.

Security is simple, with each object giving a 16 bit user ID and group ID. If the object is a valid method and is called to be executed, the security manager simply checks one of the three bits (world, group and user), to see if the method can be accessed. Note that filesystems are expected to handle the access themselves

Finnally, some objects can be 'virtual' whereby they are taken as a parameter. This means that an object that can't really be descrribed on the tree (e.g. a file), can be accessed as if it were an object, but the name is really just taken by a method further up the tree, and used to get the desired filename.

Ok, thanks for reading. I am not sure this design is completely feasable, or too complex so please comment on any suggestions or improvements you might see. Mainly - Is there a better way to implement objects in an OS?

The idea is so simple, it'll be hell to implement. It is a good idea, though, and I advise you to try it and see how it works out.

Thanks, I'll be implement it as soon as I get the underlying system layer finished off (needs a LOT of re-working due to the fact I didn't really understand portabilty, etc when I first coded it)

Now to talk about some of the other elements to the design:
The OS will be based on a microkernel design, with only the object manager, proccess manager and (possibly) the memory manager held in kernelspace. The kernel will layered, in a way, with a system layer (kind of like the HAL of win2000) underlying everything else to aid portability.

Another important element will be libraries. Each executable file will define the shared libraries it wishes to use. This could be usefull, for example, when a programmer wants to port a posix or win2k app to the OS, the simply change the executable file format, and request the use of a library mirroring say, the posix library.

Finnaly a little more has advanced on my ideas for security. One idea is that of overrides. Overides are special privalledges that can be given to a user to allow them to do certain things, for example, to be able to execute any method without the necessary privalledges, kind of like having root access. Also, as all calls to object essentially travel through one single access system call, it is possible to monitor the calls a program makes to other drivers, etc. This monitoring could be extremly usefull in things like virus prevention, as a suspicious program's behaviour could easily be tracked for any dangerous activities.

Please do comment as I am interested in what other people think of these ideas.

im not sure if mine would be realistic and like many otheres would never be finished.

goal: right now, something that works so that i dont have to see windows and deal with the microsoft bs. my os would be geared more to the people that want to see whats happening in the internal of there computers.

ideas: as far as system messages, im thinking about when a program starts it tells my os what bios peramiters it wants and is sent to the program. mostly due to the fact that the programmer might be looking for somthing specific. i would probably do a desktop running an active command line. were if theres no program running the user can just start typing and see it on the bottom left of the screen. as far as the gui. im wondering if it would be possible to have a 3d display of the processor, ram, drives, and perifial devices.

currently learning as much as i can about assembly so that i can have the highest efficency possible. im wondering if would be able to use opengl or would have to make my own graphics functions.

feedback would be appreciated

:-\ I'm afraid that hardware accellerated 3d is a dream for us hobbyists that will probably never come true. The problem is that the major vendors of 3d-hardware (nvidia and ati) are unwilling to give out hardware specifications to fellow developers, instead they provide drivers for the major OS's thereselves.

So, after doing the basic OS functionality and services (which will probably get more and more, as you will discover), you might want to look at porting MESA, so you'll get a quite complete implementation of OpenGL in software, mostly without hw-accelleration, however.

cheers Joe

well even if comes down to it theres always reverse engineering. even thou that wont look nice at first.

not sure what it would be called but as far as creating programs. i will probably use somthing like basic(scripting), and an assembler for those that know what there doing. there will be libraries of code and misc functions that will be loaded into memory with the program if it requires it. been reading alot of the post. there are some really good ideas.

there is good news! there is a video card that is coming out, and it is open source. It has feature like opengl, and other forms of acceleration. CHeck it out. I think its called The open source graphics project.

How can a "video card" be open source? If you mean the drivers then that doesn't really help much anyway since unless everyone is going to use the card it won't help support other cards.

I think he means that the hardware specifications are given away for free.