5 ms·

Well it's lack of security makes it probably not an OS you'd want run untrusted code on. Like if you made a browser for it I'm not sure it would be easy to sand

by VieElm 11y ago

Well it's lack of security makes it probably not an OS you'd want run untrusted code on. Like if you made a browser for it I'm not sure it would be easy to sandbox it to protect your computer from serious harm. Any program can read from and write to any part of memory if I recall correctly.

x5n1 11y ago
on the other hand the chances of coming across a virus made for TempleOS is rather unlikely.
- S4M 11y ago
  As long as it has very little users who are all super tech savvy.
MichaelGG 11y ago
Please explain how that's different from today on other OSes. A JavaScript exploit or other browser corruption is still an issue on current browsers, right? (I only see one Firefox process on my machine, so I'm gonna guess if you break the browser, you have code exec with my user access level.)
- masklinn 11y ago
  A Javascript browser exploit is still an issue, however it won't usually be able to read and write to kernel memory. TempleOS runs entirely in ring0. That means any exploit whatsoever and the exploiter can not just access some of your data, they own your machine entirely from the kernel up. http://www.templeos.org/TempleOS.html http://www.templeos.org/TempleOS.html is a good explanation of the point and purpose of the project, one which is reasonable and makes perfect sense. It explains why a TempleOS machine should not ever run unchecked third-party programs (let alone be on any kind of network), but could be an excellent OS to use on a remote abandoned island.
  - MichaelGG 11y ago
    Could you elaborate on the difference kernel vs user as far as the end user is concerned? I'm pretty sure that we've seen how damaging CTOs opening Office docs can be. And web browsers seemed to take off before Windows NT was the more popular desktop kernel.
    - masklinn 11y ago
      > Could you elaborate on the difference kernel vs user as far as the end user is concerned? * No possibility of a secure experience via strict privilege separation (e.g. strict usage of multiple account, inconvenient but protects against alteration of personal data) * A ring0 program has unfettered access to the hardware, so the machine itself may be compromised, a breach is not "format & reinstall" let alone "run a bunch of antiviruses" it's possibly "throw the whole machine into the bin and buy a new one". > And web browsers seemed to take off before Windows NT was the more popular desktop kernel. Windows 98 didn't run in ring0. It was crap, but not that crap.
      - moreInfo1234 11y ago
        To elaborate on the reasoning behind why it may be necessary to throw the machine out, for the people who aren't familiar: Given full access to the hardware, it's possible (though I haven't tested it to be certain) to flash the BIOS. The machine could be bricked by a remote exploit.
        masklinn 11y ago
        > Given full access to the hardware, it's possible (though I haven't tested it to be certain) to flash the BIOS. Or the firmware in hardware parts. An attacker with the know-how can not only brick but control your GPU or SSD.
      - MichaelGG 11y ago
        In the context of getting completely compromised, I'm not sure the cost of another computer really adds a lot.
- lucozade 11y ago
  > you have code exec with my user access level That's the difference. TempleOS has no access restrictions. It's not intended for either multiple users or networking so it really hasn't got even basic security e.g. processes having separate address spaces. For all that, it's still pretty impressive but it wouldn't be suitable for a general purpose OS for most people.
  - vezzy-fnord 11y ago
    You can still have security even with a single flat address space, provided you create some capability model or enforce communication boundaries in some other way. From then on memory protection is on a different level than the process.
    - lucozade 11y ago
      Indeed. I wasn't suggesting it was an unsolved problem. Just that it's not part of TempleOS. Same with file permissions. I have no idea if it's something that Terry has thought about but, from what I've read, it's just not a priority: he's been writing a single-user, network isolated system.
- kpcyrd 11y ago
  I'm not sure why this is getting downvoted, the point is very valid. In most cases it's trivial to get root if you can tamper with the environment of a user that gets root at some point. https://xkcd.com/1200/ https://xkcd.com/1200/
- mikeash 11y ago
  Chrome runs the rendering engine and JavaScript stuff in a sandboxed process that has almost no privileges. Escaping from that is possible if there's a vulnerability in the sandbox, but now you need to combine at least two vulnerabilities which makes it substantially harder.

by VieElm 11y ago

x5n1 11y ago

on the other hand the chances of coming across a virus made for TempleOS is rather unlikely.

S4M 11y ago
As long as it has very little users who are all super tech savvy.

MichaelGG 11y ago

Please explain how that's different from today on other OSes. A JavaScript exploit or other browser corruption is still an issue on current browsers, right? (I only see one Firefox process on my machine, so I'm gonna guess if you break the browser, you have code exec with my user access level.)

masklinn 11y ago
A Javascript browser exploit is still an issue, however it won't usually be able to read and write to kernel memory. TempleOS runs entirely in ring0. That means any exploit whatsoever and the exploiter can not just access some of your data, they own your machine entirely from the kernel up. http://www.templeos.org/TempleOS.html http://www.templeos.org/TempleOS.html is a good explanation of the point and purpose of the project, one which is reasonable and makes perfect sense. It explains why a TempleOS machine should not ever run unchecked third-party programs (let alone be on any kind of network), but could be an excellent OS to use on a remote abandoned island.
- MichaelGG 11y ago
  Could you elaborate on the difference kernel vs user as far as the end user is concerned? I'm pretty sure that we've seen how damaging CTOs opening Office docs can be. And web browsers seemed to take off before Windows NT was the more popular desktop kernel.
  - masklinn 11y ago
    > Could you elaborate on the difference kernel vs user as far as the end user is concerned? * No possibility of a secure experience via strict privilege separation (e.g. strict usage of multiple account, inconvenient but protects against alteration of personal data) * A ring0 program has unfettered access to the hardware, so the machine itself may be compromised, a breach is not "format & reinstall" let alone "run a bunch of antiviruses" it's possibly "throw the whole machine into the bin and buy a new one". > And web browsers seemed to take off before Windows NT was the more popular desktop kernel. Windows 98 didn't run in ring0. It was crap, but not that crap.
    - moreInfo1234 11y ago
      To elaborate on the reasoning behind why it may be necessary to throw the machine out, for the people who aren't familiar: Given full access to the hardware, it's possible (though I haven't tested it to be certain) to flash the BIOS. The machine could be bricked by a remote exploit.
      - masklinn 11y ago
        > Given full access to the hardware, it's possible (though I haven't tested it to be certain) to flash the BIOS. Or the firmware in hardware parts. An attacker with the know-how can not only brick but control your GPU or SSD.
    - MichaelGG 11y ago
      In the context of getting completely compromised, I'm not sure the cost of another computer really adds a lot.
lucozade 11y ago
> you have code exec with my user access level That's the difference. TempleOS has no access restrictions. It's not intended for either multiple users or networking so it really hasn't got even basic security e.g. processes having separate address spaces. For all that, it's still pretty impressive but it wouldn't be suitable for a general purpose OS for most people.
- vezzy-fnord 11y ago
  You can still have security even with a single flat address space, provided you create some capability model or enforce communication boundaries in some other way. From then on memory protection is on a different level than the process.
  - lucozade 11y ago
    Indeed. I wasn't suggesting it was an unsolved problem. Just that it's not part of TempleOS. Same with file permissions. I have no idea if it's something that Terry has thought about but, from what I've read, it's just not a priority: he's been writing a single-user, network isolated system.
kpcyrd 11y ago
I'm not sure why this is getting downvoted, the point is very valid. In most cases it's trivial to get root if you can tamper with the environment of a user that gets root at some point. https://xkcd.com/1200/ https://xkcd.com/1200/
mikeash 11y ago
Chrome runs the rendering engine and JavaScript stuff in a sandboxed process that has almost no privileges. Escaping from that is possible if there's a vulnerability in the sandbox, but now you need to combine at least two vulnerabilities which makes it substantially harder.