Jump to content




Hacking an OS

help

21 replies to this topic

#1 Iredstone7648

  • Members
  • 14 posts

Posted 19 January 2017 - 10:43 PM

Hello Everyone!

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 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,452 posts

Posted 19 January 2017 - 10:49 PM

The computer belongs to the user. Why should she be prevented from editing whichever files she chooses? I'm of the opinion that the user should be allowed to perform any actions he chooses to.

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 Iredstone7648

  • Members
  • 14 posts

Posted 19 January 2017 - 11:21 PM

Well, say you get a floppy disk and bypass startup. This could be done by anyone. All they would have to do is go in with the shell and edit the files to have instant access.

Edited by Iredstone7648, 19 January 2017 - 11:22 PM.


#4 KingofGamesYami

  • Members
  • 3,002 posts
  • LocationUnited States of America

Posted 19 January 2017 - 11:25 PM

If they bypass startup there is literally nothing you can stop them from doing.

#5 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,452 posts

Posted 19 January 2017 - 11:27 PM

Yes, that's true. It also accurately mirrors the situation in the real world, where if an attacker gains physical access to a system, they can do essentially anything they want to it.

#6 Iredstone7648

  • Members
  • 14 posts

Posted 19 January 2017 - 11:38 PM

Ok thanks guys. I was looking into modifying fs.isReadOnly but that would only work for my ROM file. Other than that, there's nothing more to do.

Edited by Iredstone7648, 19 January 2017 - 11:38 PM.


#7 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 20 January 2017 - 12:23 AM

Although local access to a system and sufficient time allows most any action, that doesn't mean you have to give away your user's passwords. Consider researching password hashing.

#8 exosceleton

  • Members
  • 52 posts
  • LocationUmm... Mars.

Posted 20 January 2017 - 07:25 AM

You could instead of overwriting os.isReadOnly, overwrite the fs functions such as fs.list and fs.open to only detect/allow access to non system files.

#9 Piorjade

  • Members
  • 244 posts
  • LocationComputer, Germany

Posted 20 January 2017 - 02:02 PM

settings.set("shell.allow_disk_startup", false)


#10 Sewbacca

  • Members
  • 450 posts
  • LocationStar Wars

Posted 20 January 2017 - 08:51 PM

View PostIredstone7648, on 19 January 2017 - 11:38 PM, said:

Ok thanks guys. I was looking into modifying fs.isReadOnly but that would only work for my ROM file. Other than that, there's nothing more to do.

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.

#11 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 21 January 2017 - 12:47 AM

View PostPiorjade, on 20 January 2017 - 02:02 PM, said:

settings.set("shell.allow_disk_startup", false)

That will not prevent users from picking the computer up and slotting it into a disk drive.

#12 houseofkraft

  • Members
  • 170 posts
  • LocationUSA

Posted 22 January 2017 - 12:52 AM

If you want a way to make files read-only, you just need to paste this script into a file

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


#13 Sewbacca

  • Members
  • 450 posts
  • LocationStar Wars

Posted 22 January 2017 - 07:51 PM

View Posthouseofkraft, on 22 January 2017 - 12:52 AM, said:

If you want a way to make files read-only, you just need to paste this script into a file

(snip)

The same thing and more does FSector.

Edited by Sewbacca, 22 January 2017 - 07:52 PM.


#14 hbomb79

  • Members
  • 352 posts
  • LocationOrewa, New Zealand

Posted 22 January 2017 - 10:24 PM

View PostSewbacca, on 22 January 2017 - 07:51 PM, said:

The same thing and more does FSector.

The shameless self-promotion is strong in this one.

#15 Anavrins

  • Members
  • 775 posts

Posted 23 January 2017 - 03:32 AM

The shameful fact that both House's and FSector's solution are useless for what OPs is asking.
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 Sewbacca

  • Members
  • 450 posts
  • LocationStar Wars

Posted 26 January 2017 - 11:07 AM

View PostHbomb_79, on 22 January 2017 - 10:24 PM, said:

View PostSewbacca, on 22 January 2017 - 07:51 PM, said:

The same thing and more does FSector.

The shameless self-promotion is strong in this one.
Yeah sorry, I forgot to mention, that it's productplacement. =P

Edited by Sewbacca, 26 January 2017 - 11:09 AM.


#17 HaddockDev

  • Members
  • 61 posts
  • LocationSomewhere, deep down under a rainbow.

Posted 02 February 2017 - 08:21 PM

You could do some encryption (not recommended though)
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 zephar26

  • Members
  • 10 posts
  • LocationSomewhere Over the Rainbow

Posted 02 February 2017 - 09:25 PM

I know I'm a bit late to the party on this thread, but I've heard a particular statement that I think applies well here.

"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 Anavrins

  • Members
  • 775 posts

Posted 02 February 2017 - 09:57 PM

View PostHaddock, on 02 February 2017 - 08:21 PM, said:

You could do some encryption (not recommended though)
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.
In case you're referencing my post, just letting you know that both programs I stated does not decrypt on startup, but overrides fs.open to read an encrypted file and return an unencrypted handler.
Data never get's decrypted on disk, only in memory.
Of course your method is flawed, but not this one.

#20 HaddockDev

  • Members
  • 61 posts
  • LocationSomewhere, deep down under a rainbow.

Posted 02 February 2017 - 10:03 PM

View PostAnavrins, on 02 February 2017 - 09:57 PM, said:

View PostHaddock, on 02 February 2017 - 08:21 PM, said:

You could do some encryption (not recommended though)
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.
In case you're referencing my post, just letting you know that both programs I stated does not decrypt on startup, but overrides fs.open to read an encrypted file and return an unencrypted handler.
Data never get's decrypted on disk, only in memory.
Of course your method is flawed, but not this one.
No, wasn't referencing your post, and yes I know that method has more holes than account password management in Windows.

[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