#1
Posted 19 January 2017 - 10:43 PM
I am currently working on an operating system and came across the problem of hacking. Once the user is in, he can use the text editor to edit system files such as password storage, password checks, or anything he chooses.
I would really appreciate any solutions to this problem! Thanks for checking out my post!
#2
Posted 19 January 2017 - 10:49 PM
It sounds like you may want to set up some system that uses access control lists to conditionally allow or deny file read/write operations based on user accounts, though.
#3
Posted 19 January 2017 - 11:21 PM
Edited by Iredstone7648, 19 January 2017 - 11:22 PM.
#4
Posted 19 January 2017 - 11:25 PM
#5
Posted 19 January 2017 - 11:27 PM
#6
Posted 19 January 2017 - 11:38 PM
Edited by Iredstone7648, 19 January 2017 - 11:38 PM.
#7
Posted 20 January 2017 - 12:23 AM
#8
Posted 20 January 2017 - 07:25 AM
#9
Posted 20 January 2017 - 02:02 PM
settings.set("shell.allow_disk_startup", false)
#10
Posted 20 January 2017 - 08:51 PM
Iredstone7648, on 19 January 2017 - 11:38 PM, said:
It seems like, you are looking for FSector.
You can create two files systems. An OS system, access to everything and an user system, just access to user files.
So while the system is running, you cannot gain access to system files.
#12
Posted 22 January 2017 - 12:52 AM
local protected = { "rom", "path/to/protected/file", "maybe/another/path" } function tableFind(arr, text) local found = false for k,v in pairs(arr) do if v == text then found = true end end return found end fs.isReadOnly = function(path) return tableFind(protected, path) end local oldOpen = fs.open fs.open = function(file, mode) if tableFind(protected, path) then oldOpen(file, "r") else oldOpen(file, mode) end end -- Sorry about the indentation problem local oldDelete = fs.delete fs.delete = function(file) if tableFind(protected, file) then return error("Access Denied") else oldDelete(file) end end
#15
Posted 23 January 2017 - 03:32 AM
There isn't really any way to prevent this without modifying the rom in versions prior to 1.77, nor past it, as stated by BombBloke.
A somewhat working solution would be to use something that will encrypt your whole filesystem, something like EncryptFS, or my unreleased one.
With that, an attacker who gains access to your filesystem, whether it be from disk bypass, drive bypass, even from a server administrator, will be able to modify and delete your files, but will not be able to read it's true content.
Edited by Anavrins, 23 January 2017 - 03:40 AM.
#16
Posted 26 January 2017 - 11:07 AM
Hbomb_79, on 22 January 2017 - 10:24 PM, said:
Sewbacca, on 22 January 2017 - 07:51 PM, said:
The shameless self-promotion is strong in this one.
Edited by Sewbacca, 26 January 2017 - 11:09 AM.
#17
Posted 02 February 2017 - 08:21 PM
Maybe have the user input a password to decrypt the system files on startup, so if somebody puts in a disk they wouldn't be able to modify the files without knowing the users password.
To be honest, I find it really flawed, but its worth a try.
Another idea if your testing security is to publish it on GitHub and get a few people to break the security.
One more idea is to go do something like Google does when it finds out that Chrome OS has been tampered with. Still, flawed.
The only other piece of advice I can give is to think like an attacker:
Think of attack vector. Try attack vector. Fix if required.
Rinse and repeat.
Edited by Haddock, 02 February 2017 - 08:22 PM.
#18
Posted 02 February 2017 - 09:25 PM
"Physical access is full access."
If you want your computers to be secure, don't put them in open spaces where just anyone can get to them.
If this is a case where you can't do that, then you can always use
os.pullEvent = os.pullEventRaw
Which will ignore all termination requests, but I'd be careful with using this.
For those even more curious, I know there is a way to also make your computer not boot to disk first, if you're concerned with someone using a floppy-break program on your computer as well. I also consider that to be a bit dangerous, development wise, and would recommend against using it.
Edited by zephar26, 02 February 2017 - 09:29 PM.
#19
Posted 02 February 2017 - 09:57 PM
Haddock, on 02 February 2017 - 08:21 PM, said:
Maybe have the user input a password to decrypt the system files on startup, so if somebody puts in a disk they wouldn't be able to modify the files without knowing the users password.
To be honest, I find it really flawed, but its worth a try.
Data never get's decrypted on disk, only in memory.
Of course your method is flawed, but not this one.
#20
Posted 02 February 2017 - 10:03 PM
Anavrins, on 02 February 2017 - 09:57 PM, said:
Haddock, on 02 February 2017 - 08:21 PM, said:
Maybe have the user input a password to decrypt the system files on startup, so if somebody puts in a disk they wouldn't be able to modify the files without knowing the users password.
To be honest, I find it really flawed, but its worth a try.
Data never get's decrypted on disk, only in memory.
Of course your method is flawed, but not this one.
[offtopic]No offence, but your program reminds me of the OneHalf virus of the MS-DOS days.[/offtopic]
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users