Would this work in an os?
When logging in, each user has a partition that can be resized by root. Any password will get you loged in, but any opened file is decrypted with that password, and when a file is saved, it checks the password, so a hacker would have to log out every time a new password is entered.
Also, would it be good if the kernel randomly placed buffers at startup, so a programme that gets access to those places still needs to use the kernel's functions for the very low level stuff?
would this way of security work?
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:would this way of security work?
having to type a password everytime i save a file ?? and will this imply that i can't have auto-saving or disk cache of my webbrowser ?
imho, if all you want to do is force re-login when password changes, it sounds like a bomb-to-kill-a-fly problem ...
also, why should the kernel place its buffer randomly as they're expected to be accessible from kernel only ? what kind of attack are you trying to prevent with this ?
imho, if all you want to do is force re-login when password changes, it sounds like a bomb-to-kill-a-fly problem ...
also, why should the kernel place its buffer randomly as they're expected to be accessible from kernel only ? what kind of attack are you trying to prevent with this ?
-
mystran
Re:would this way of security work?
I'd first define what you want from your security, then think of means to implement that.
Most common OSs have security something like this:
- each process can only access it's own address space, except by calling kernel functions
- each user (and process running with the priviledges of a user) can only access files/processes/functions that the user have been given access to (by ownership of some other method)
Personally I'd prefer something like this:
- each process can only access it's own address space and functions which another process has granted it
- the process representing users priviledges can only grant priviledges that user has authorized it to give (on per resouce, per process basis)
- user can only authorize priviledges that some other user already holding that priviledge has granted him
Depending which one you want, you want different methods. For both of the above, you want to use virtual memory to protect address spaces from each other. For the first one you also want ACLs. For the second one you want capabilities (and probably some kind of ACL's too).
There are other models. What every model protects, is a matter of "proving some properties of the system based on some core set of assumptions".
An assumption in the first model for example assumes that "programs are bugless, or those bugs can't be exploited".
The second model on the other hand only assumes that "there is some central authority (say kernel) that can be trusted".
Basicly, you could just as well say that DOS is a secure system, if every file is accessed using a password. That's true, in a way, if your goal is to only protect files. Ofcourse it also assumes that "the encryption is uncrackable" and "the passwords are strong enough".
Just my ?0.05. (That's the smallest coin in use in Finland.)
Most common OSs have security something like this:
- each process can only access it's own address space, except by calling kernel functions
- each user (and process running with the priviledges of a user) can only access files/processes/functions that the user have been given access to (by ownership of some other method)
Personally I'd prefer something like this:
- each process can only access it's own address space and functions which another process has granted it
- the process representing users priviledges can only grant priviledges that user has authorized it to give (on per resouce, per process basis)
- user can only authorize priviledges that some other user already holding that priviledge has granted him
Depending which one you want, you want different methods. For both of the above, you want to use virtual memory to protect address spaces from each other. For the first one you also want ACLs. For the second one you want capabilities (and probably some kind of ACL's too).
There are other models. What every model protects, is a matter of "proving some properties of the system based on some core set of assumptions".
An assumption in the first model for example assumes that "programs are bugless, or those bugs can't be exploited".
The second model on the other hand only assumes that "there is some central authority (say kernel) that can be trusted".
Basicly, you could just as well say that DOS is a secure system, if every file is accessed using a password. That's true, in a way, if your goal is to only protect files. Ofcourse it also assumes that "the encryption is uncrackable" and "the passwords are strong enough".
Just my ?0.05. (That's the smallest coin in use in Finland.)
-
bkilgore
Re:would this way of security work?
I got the impression from kernel32's post that what he was trying to say is that anytime there is a file with a different password than the one you were logged in with, you couldn't open it. So you'd have to log out and back in for that file, and then again if there was another file with a different password.Pype.Clicker wrote: having to type a password everytime i save a file ?? and will this imply that i can't have auto-saving or disk cache of my webbrowser ?
imho, if all you want to do is force re-login when password changes, it sounds like a bomb-to-kill-a-fly problem ...
So you wouldn't have to type your password in every time you did something, it would just use the password you logged in with.
I'm still not sure that's a very secure system, but I at least don't think it's quite as inconvenient as you thought.
-
Tux
Re:would this way of security work?
Hmm, imho I would add a timer to logout of the OS. Like, if the user doesn't do something for some time, it logs out but keeps the program data intact. Make it a feature which an user can turn on/off. Another solution would be to have users be able to set the encrypted flag and password. E.G. Password protect files. Or password protect directories. So you only have to type the password once to enter the directory.
Re:would this way of security work?
..
Last edited by Perica on Sun Dec 03, 2006 9:15 pm, edited 1 time in total.
-
tom1000000
Re:would this way of security work?
IMHO you should keep the security system as simple as possible. Provide the absolute minimum functionality necessary (while still being useful of course).
If you create lots of different security options, there's a good chance the user will make a mistake, and there's also a good chance the millions of lines of code you wrote may have a mistake as well.
If you create lots of different security options, there's a good chance the user will make a mistake, and there's also a good chance the millions of lines of code you wrote may have a mistake as well.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:would this way of security work?
my suggestion would be to have a "user personnality" authentified by a master password for that personnality. The Master Password(tm) is used to decrypt a file-password (which has StorableItemName -> Item Password database with all files/directories the user want to protect)
By generating Item Password randomly at Item creation, you can improve security (cracking the password for file A don't give a clue for password of B, and the MasterPassword is hard to crack because you have no hint on the ItemPasswords database content (provided that StorableItemNames aren't encrypted)), and changing the user-typed password only means to re-encrypt the Password Database (1 file)
Hope you like this approach. that's all i have to offer
Note that it's much inspired from "session keys" in network transmissions :-p
By generating Item Password randomly at Item creation, you can improve security (cracking the password for file A don't give a clue for password of B, and the MasterPassword is hard to crack because you have no hint on the ItemPasswords database content (provided that StorableItemNames aren't encrypted)), and changing the user-typed password only means to re-encrypt the Password Database (1 file)
Hope you like this approach. that's all i have to offer
Note that it's much inspired from "session keys" in network transmissions :-p