Security Versus Programming Language

[QuantumQuest]

I presume that buffer overflow, heap management, and pointer validation are the shortcomings of C that lead to insecurity. But the broader implications make me curious.

For me, C was not the first programming language I learned but it was by far the most influential and helpful language I've ever met. I have no doubt that the above quoted are shortcomings of C but to be fair the advantages and drawbacks of any programming language is something that can't be studied without reference to a specific period of time, to the specific hardware architectures and systems that it is / was run on - be it an application, a compiler or more importantly an OS and last but not least, the networking and internetworking scene of the time considered. I think that it does no justice to a programming language which has directly and indirectly influenced and in fact has paved the way to develop most modern software like C, to just call it an insecure language - I don't say that the original post does this, I just say it for clarification purposes.

As is widely known, C was originally designed for and implemented on the UNIX operating system on the DEC PDP-ll by Dennis Ritchie and it is a descendant of B which was influenced by BCPL. At the time created, C fulfilled specific goals: a general-purpose programming language which features economy of expression, modern control flow and data structures, and a rich set of operators. As a language near the "bare metal" but with a lot of high level features, it was inevitable that a lot of its power could potentially some day be utilized in innocuously inappropriate but potentially dangerous or purely malicious ways.

This became evident much later but in any case I don't think that it is due to intrinsic weaknesses - at least not so much, as it is due to the way that software was developed including libraries which to be fair they also need an appropriate time - frame, each one, to be judged fairly. There has been a lot of improving by the ANSI standards through years but again, especially for the case of OSes like UNIX and its descendants and Windows, all of which have a form of C "ticking" at their heart, the comlexity of the software itself combined with high demands for speed and flexibility does not leave much room to a programmer to be absolutely strict on security standards and on the other hand, real gurus of C - and C++ for that matter, are at least as far as I know very few - even nowadays, compared to the total number of people who are professional programmers.

The point for me is that C has done a tremendous job in the software industry for decades while hardware technology and networks / communications has, during this same time, improved so much. It is really difficult for me to think of another programming language that could have such a long-standing positive impact for machines and OSes in widespread use.

1. What other features of a programming language directly aid security of the products?
2. Are the security implications of the language different for OS compared to other software?
3. My bias leans toward KISS. I suspect compiler/library vulnerabilities in very high level languages that lead to insecurities in the infrastructure. Are there studies that quantify complexity versus security? I mean statistically, not anecdotally. Perhaps DOD studies on Ada.

For the first, I would just say that features that aid security may be at odds with speed and flexibility and simpicity for the programmer, at least when taken to the extreme. There is no silver bullet here in my opinion. Absolute security can only come from hardware - as has already been noted, but this is not a silver bullet either, as we don't talk about dedicated OSes here or software constructs / systems in general, but for general purpose ones.

For the second, I think that the security implications are definitely different for OSes compared to other software, given the operations / tasks that the OS performs regarding hardware, itself and the software applications that run on it.The impact of security holes in an OS is combined and magnified in many cases and as the complexity of the OS increases so does the complexity of even idefintifying a potential hole. On the other hand a security hole in an application is in general and at average, more easily identified.

For the third, I think that KISS is a good general principle but unforunately, it may mean different things to different people at times and in any form, it is not always feasible to be followed. Software vulnerabilities are indeed in my opinion responsible for insecurities but this is inevitable: hardware must be fast and cheap and in many cases non-dedicated - at least for systems in widespread use, so software must do the job under the pressure of fast development, quick and dirty solutions in many cases, flexibility and simplicity. I think that the only think anyone sees at the end of this tunnel is "Welcome to the vulnerabilities realm".

In a von-Neumann architecture, we compile and link programs to create executable code. That program is data to the compiler and linker. But then we sprinkle it with pixie dust and say that it is now code. Isn't that the mechanism for almost all modern malware?

It may lead to potential vulnerabilities but with a lot of factors in between. Von Neumann architecture was a real innovation in my opinion, as it solved a whole lot of problems in order for computers to get into widespread use. Now, a whole lot of factors including but not limited to the evolution of hardware itself, programming and (inter)networking, come into play and mediate the final result. It isn't feasible to create cheap and secure hardware for widespread use, as it is not feasible to create ideally secure software for another multitude of reasons nor have complete control of a network and of its potential internetworking. On the other hand, can non - Von Neumann architectures be purely utilized in order to develop systems for widespread use? I think that at least for the form of such systems we have today, there is no such case.

 

[anorlunda]

can non - Von Neumann architectures be purely utilized in order to develop systems for widespread use? I think that at least for the form of such systems we have today, there is no such case.

What about cheap, mass-produced, IOT devices? They may have no user interface at all, neither GUI nor command. They have no login. They have no admin. They have no plans for future updates or patches. But they have been hijacked for ill purposes using their net connection. Smart light bulbs, doorbells, web cams, location tags, smart buttons, swallow-able drug cartridges, the list is endless.

Can we make a case that IOT devices have an architecture such that the code can never be modified via remote action? Would that not go a long way toward making them hard to hijack?

In the coming years, the world may be swamped by trillions of such IOT devices. They are manufactured in many countries, some of which may have concealed intentions. They can be marketed internationally in bulk, perhaps X dollars per ton. If they are all vulnerable to hijacking, we are in big trouble. IMO we desperately need a solution to that problem international in scope and down-scalable to devices costing a fraction of a penny each, but which nevertheless permit innovation.

 

[Rive]

Can we make a case that IOT devices have an architecture such that the code can never be modified via remote action?

That's a risk in itself what no company would like to take. In normal case for any software bug a patch can be provided, without the need of replacing the hardware itself. Fast and cheap (and inherently insecure indeed).

I don't think there is a solution (apart from keeping all the gizmo 'dumb', what I actually prefer). Keeping all the devices up to date requires far more care than possibly available. At the 'secure' price nobody would buy them.
On the long run the vulnerability of cheap IoT devices is just like the risk catching a cold.

 

[QuantumQuest]

What about cheap, mass-produced, IOT devices? They may have no user interface at all, neither GUI nor command. They have no login. They have no admin. They have no plans for future updates or patches. But they have been hijacked for ill purposes using their net connection. Smart light bulbs, doorbells, web cams, location tags, smart buttons, swallow-able drug cartridges, the list is endless.

Can we make a case that IOT devices have an architecture such that the code can never be modified via remote action? Would that not go a long way toward making them hard to hijack?

In the coming years, the world may be swamped by trillions of such IOT devices. They are manufactured in many countries, some of which may have concealed intentions. They can be marketed internationally in bulk, perhaps X dollars per ton. If they are all vulnerable to hijacking, we are in big trouble. IMO we desperately need a solution to that problem international in scope and down-scalable to devices costing a fraction of a penny each, but which nevertheless permit innovation.

Here we have to make a distinction: IoT devices have no other major component than sensors. So, you're most likely talking about the whole IoT infrastructure. The model of this infrastructure consists of an IoT device, a gateway of some kind - various mediums of communication and transports can be utilized like cellular networks, satellite networks, Bluetooth, wide-area networks (WAN) to name a few, which is utilized in order to transmit data to a cloud server or some cloud infrastructure in general where the processing takes place and finally users get notified via some type of interface e.g. alarms on a mobile phone or email sent to some computer or device etc.

So, there is no non - von Neumann model, at least as I see it. Now, it is true that there is a big number of vulnerability issues that people using / involved in the development, management and use of IoT infrastructure have to face. The most recent ones according to the OWASP Internet of Things Project
are shown here. There are various ways to remedy these vulnerabilities and measures to take but there are of course some intrinsic weaknesses in this infrastructure which will give various kinds of "inspiration" to malicious users and attackers of any sort to invent and develop new vulnerabilities again and again.

And of course, I really have no doubt that as the number of IoT devices / infrastructures increases, concealed intentions from some people or even at a country level may find a fertile ground and at least as I see it, even with countermeasures already put then, it will be rather hard to avoid massive data leaks.

 

[anorlunda]

rather hard to avoid massive data leaks.

That's not the only risk. In fact, the most alarming report I heard was that of IOT devices being hijacked into a bot net and used to help launch a DDOS attack.

When used as a bot, neither the sensors nor the normal communication channels of the device were used. It is just a CPU with a TCP/IP stack and a net connection, no different than a PC or a phone hijacked for bot use. In other words, a loose cannon. Huge numbers of loose cannons.

 

[.Scott]

C and C++ are entirely workable languages for creating a secure operating system and secure applications.

Security vulnerabilities are created by bad programming and bad software design. In the majority of cases, they are based on programming mistakes - buffer lengths that are not checked, resource arbitration that is flawed, memory that is used after it is 'free'd, password security or encryption that is not well thought out, functions reentered that are not coded for reentrancy, systems that depend on obscurity for their security. You will never have a secure system so long as you have sloppy design and coding.

Certainly operating systems contribute their share of vulnerabilities. But ultimately the OS needs to allow Adobe, Chrome, your favorite game, etc to operate. Those apps then use third party libraries that can include defects. And once those apps are running, there is nothing the OS can do if the app turns over all of its resources to malicious code.

There is no substitute for consistently good design and programming practices.

I would not promote coding in assembler (or machine language) when it can be avoided. It absolutely does not promote a secure system because that level of detail obscures the basic algorithm and implementation. The point of a programming language is to provide syntax that can be written and reviewed by people (programmers) and readily parsed by a compiler. On the other hand, it certainly pays to know exactly what code the compiler is generating since that is part of your debug environment.

 

[hmmm27]

There's an humongous thread in alt.folklore.computers circa 2005, concerning buffer overruns, that started as a crosspost from sci.crypt . 6k'ish posts. Unfortunately, trying to view it in Google Groups is giving my laptop a headache.

Long story short :

"OMG, how can we avoid 'buffer overruns' ?".
"Hire better programmers".
"But we can't afford that. Why don't we just require that C automatically checks every single array reference for out-of-bounds".
"Are you insane ?"

Doesn't matter, really : make something 'idiotproof' and the universe sees it as a challenge.

 

[FactChecker]

It's a serious weakness of C. If a language does not have a built-in, protected, size indicator as part of its standard structures, then protecting code from space overruns is a problem.

 

[.Scott]

It's a serious weakness of C. If a language does not have a built-in, protected, size indicator as part of its standard structures, then protecting code from space overruns is a problem.

And C# does. But I would not suggest dropping C and C++ in place of C#. They all have their place.
And, of course, you can borrow or create a memory management library. It won't be built in, but it'll still look good in the code.

 

[Rive]

It's a serious weakness of C. If a language does not have a built-in, protected, size indicator as part of its standard structures, then protecting code from space overruns is a problem.

Hammers has no built-in protection against hitting your fingers - that's what you expect from a hammer.
From a different angle: it is not a weakness, it is a feature...

 

[Svein]

I once wrote a document about security problems. The main document is the property of the firm I was working for at the time, but this excerpt is general (and mostly my own):

3.1.1 The “C” Language
The “C” language is terse, flexible – and quite unsecure. Other languages usually refuse to compile when they meet ambiguous constructions or parameters of the wrong type. “C” compiles everything, at most writing an error message to the console, and even that message can be suppressed.
Therefore it should be mandatory to run all “C” code that is concerned with security through the lint code checker, or even better, the splint (Secure Programming Lint) code checker. While not a substitute for good programming practices, it catches most spurious errors and ambiguities.

3.1.2 The “Buffer Overflow” Vulnerability
A frequent root cause in Microsoft security bulletins, the “Buffer Overflow” vulnerability is usually caused by uncritical use of the standard C string copy function strcpy().
What this function dos, is copying a string into a buffer. What it does not do, is checking whether the string fits inside the buffer. Therefore, strcpy() will happily keep copying the string data on top of whatever data that are adjacent to the buffer. This behavior causes all kinds of problems – from the obscure to the catastrophic.
There are several ways around this vulnerability. You can:
• Check the length of the input string (using strlen()) before copying. If the input string is longer than expected, you can raise an error or allocate a larger buffer.
• Use the safer version of strcpy(), namely strncpy(). Remember that the length parameter in strncpy() should be one less than the size of the buffer, and that the last character in the buffer should be set to ‘\0’ after the copy.
• Use strdup() instead. This function creates a duplicate of the input string and returns a pointer to the copy. Remember to get rid of the copy (free()) when you are finished with it!

3.1.3 The “Null Pointer” Vulnerability
Several “C” library functions (e.g. malloc()) return a NULL pointer to indicate an error. Sloppy coding skips testing the returned pointer for NULL and uses it as if it were a valid pointer. Writing something into location 0x0000 (=NULL) - or close by – usually introduces a catastrophic fault at an unrelated part of the software.
Security experts see unchecked null pointers as the next great vulnerability exploitation.

 

[.Scott]

I have coded thousands of strcpy()'s and they all work. Using that routine without considering buffer lengths or the possibility of invalid pointers is barely good enough for one-off code that will never see light of day. It is not good enough for even the lowest impact application that is going to be made public.

“C” compiles everything, at most writing an error message to the console, and even that message can be suppressed.

My last couple of jobs have involved mission-critical and life-critical systems where you buy additional tools to look for additional warnings - which you then resolve. But even with less critical systems (such as video processing) there were software standards.
Allowing any warning to go unaddressed allows new warning messages to get lost in the clutter.

I am astounded that major corporations need to resort to things like C# to hold to coding standards. It suggests that there are armies of programmers who aren't eager to do their full jobs.

 

[Mark44]

3.1.2 The “Buffer Overflow” Vulnerability
A frequent root cause in Microsoft security bulletins, the “Buffer Overflow” vulnerability is usually caused by uncritical use of the standard C string copy function strcpy().

Or scanf()...

Use the safer version of strcpy(), namely strncpy().

Several versions of Visual Studio ago, Microsoft introduced s_scanf() and several other input functions in the C standard library, which take an additional parameter when character arrays are to be input. Current VS versions have deprecated the older, unsecure, versions.

 

[Nugatory]

My point is that none of this has anything to do with whether the executable code itself is compiled. You are focusing on compilation and linking as though that's the problem, but it isn't. The problem is executable code not having protection against being changed to something other than what the user wanted it to be.

Compilation and linking is indeed a part of the problem, although it is better described as end-to-end validation of the entire toolchain. A good summary of the issue is Ken Thompson’s 1984 Turing Award lecture: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf (although it does contain some anachronisms: written before any significant uptake of multi-byte character encodings; no discussion of hashing and signing; ...).

Protecting executable code is also only part of the problem, as altering the code is only one way of persuading code at a privilege level other than your own to do something you are not be allowed. SQL injection attacks are a trivial example, but there are many more.

And to return to the subject in the thread title... The idea that one programming language might be more secure than another is a snare and a delusion. One set of development practices may lead to more secure designs and implementations (confusing these two is another fertile source of security vulnerabilities) than another, and as part of defining these practices we may decide that one programming language will integrate with these practices better than another, but that tells us more about our approach than about whether one language is more secure than another.

The most secure system I ever worked with was written completely in C, including the ROM-resident boot loader. The very small microkernel that managed mapping from virtual to physical addresses (aggressive use of the x86 architecture’s segmentation machinery here) was formally validated, and although it is not feasible to formally validate a toolchain that includes a C compiler, the toolchain was carefully audited. The design goal was to be able run arbitrary binaries outside of the microkernel with confidence that compartmentalization (yes, this was a national security application) could not be violated in either direction.

 

[anorlunda]

A good summary of the issue is Ken Thompson’s 1984 Turing Award lecture: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

That lecture supports the idea that secure software is an oxymoron, because obviously, code is used by users other than the author.

The moral is obvious. You can't trust code that you did not totally create yourself.

The most secure system I ever worked with was written completely in C, including the ROM-resident boot loader.

Ken Thompson would not have trusted your secure system because he didn't write it. Details of why you trust it are irrelevant to Mr. Thompson.

But that level of philosophy is far above the properties of any SW, any language, any hardware.

A good discussion of trust is given in this book by Bruce Schneier. Liars and Outliers: Enabling the Trust that Society Needs to Thrive

If we trust nothing, then we become paralyzed and unable to function. We suffer from self-inflicted pain. If we trust too much, then we are vulnerable to externally-inflicted pain.

But I am optimistic that someday we may learn how to manage trust. Therefore continuing interest in the topic is warranted.

 

[FactChecker]

I have coded thousands of strcpy()'s and they all work.

Have they all been attacked?

Using that routine without considering buffer lengths or the possibility of invalid pointers is barely good enough for one-off code that will never see light of day. It is not good enough for even the lowest impact application that is going to be made public.

Perfect people make perfect code. Imperfect people make imperfect code. It is good to have languages and tools that can help the imperfect people.

 

[Rive]

I am astounded that major corporations need to resort to things like C# to hold to coding standards. It suggests that there are armies of programmers who aren't eager to do their full jobs.

Well. More like: there are armies of coders (appointed as programmers) who does not even know what's their job would be.
I think that's the sad reality of 'security'.

 

[.Scott]

Have they all been attacked?Perfect people make perfect code. Imperfect people make imperfect code. It is good to have languages and tools that can help the imperfect people.

This isn't an issue of perfect vs. imperfect. You shouldn't use strcpy() unless you know your destination is large enough. The normal mistake is not for someone to miscalculate, but to make assumptions that should never be made - like assuming that input from the outside world is going to be correct.

And yes they are attacked. I attacked them myself.

 

[Baluncore]

And to return to the subject in the thread title... The idea that one programming language might be more secure than another is a snare and a delusion.

I agree. Security does not come as a score out of 100. A system is secure or it is not.

To be secure the hardware must;
1. Differentiate between executable code and data.
2. Have hardware bounds checking on virtual memory pages used for code and for data.
3. Restrict privileged instructions to the kernel of the OS.

When you compile a C source and execute it on that system, the task is restricted to allocated resources and cannot detect or interfere with other users or resources. Any bounds transgression, attempt to execute data, or modify code, will result in an exception seen by the OS and not by the task.

Security comes from the hardware.
You cannot build a castle, or a tower of babel, on a foundation of sand.

 

[Vanadium 50]

I'm going to be a bit contrary and blame C.

The 8088 was a 16 bit computer, and 16 bit addresses go to 64k. To address more space (the original IBM PC has 640k of memory), addresses were in two parts: a segment and an offset. The physical address was (segment * 16) + offset, so 1 MB was theoretically addressable. There were four segments, CS, DS, SS and ES, intended for code, data, stack and "extra", but there were no consequences (other than what was caused by bad programming) for using them any way you wanted.

Because the physical address was easily calculable, even across segments, C pointer arithmetic worked, even across segments.

Enter the 80286. It was to address 16 MB, and it was to enforce this data model. CS, DS and SS could not overlap (not sure about ES, but probably the same) and depending on a process' privilege level or ring had varying degrees of access to these areas in memory. It couldn't (without a hack) deal with the old segment+offset addressing, so it replaced "segment" with "selector", a 16-bit number which "uniquely identifies one of 16K possible segemnts in a task's virtual address space" but "the selector value does not specify the segment's location in physical memory."

C programmers hated it. C was the dominant language at the time, and C programmers really hated it. This change killed the single 20-bit address space and it killed pointer arithmetic for pointers more than 64k apart. It's hard to express the degree of hate programmers had for it if you weren't there. It was a revolt - with few exceptions, programmers simply refused to program this way, instead using just the lowest 1MB of memory where they could pretend they had an 8086.

So the customers chose convenience over security, and the vendors saw this and provided exactly that. And that lesson has not been forgotten.

 

[Vanadium 50]

You cannot build a castle, or a tower of babel, on a foundation of sand.

You can, however, build one on a swamp:

 

[Svein]

Security comes from the hardware.

Well, no. The hardware (with a few exceptions) does what it is designed to do. Of course you can use it wrongly ("it is not the gun that kills, but the man using it").

An anecdote: When people started using the Ethernet to transport IP packets, they needed a way to map IP addresses (with their own rules and peculiarities) to Ethernet addresses (with their rules etc.). To handle this, a protocol was devised, the Address Resolution Protocol (ARP). In short, when you wanted the Ethernet address matching a given IP address, you sent an Ethernet broadcast asking "Who has got this IP address?" and you would (hopefully) get an answer - also using the Ethernet broadcast.

But then - in the name of efficiency - somebody thought of caching those mappings for a while (in case you needed it again soon). Well and useful.

Next optimization was when somebody thought it useful to cache all ARP answers (even if you had not used ARP recently) in case you would need that address mapping. And the address mapping everybody needed was the Ethernet address of the router to the outside world. So - if somebody got access to the network, they could use ARP to get the Ethernet address of the router, store it, and then send out an ARP reply mapping the IP address of the router to themselves. Thus every packet to the outside would pass through this rogue machine...

 

[Rive]

Security comes from the hardware.

That's like one leg of a three legged stool claiming all the glory of being THE support for itself. Just - no.
There are some basic requirements for the hardware but right now most hardware is able to provide that much.

Has hardware anything to do with script worms, for example?

 

[.Scott]

It couldn't (without a hack) deal with the old segment+offset addressing, so it replaced "segment" with "selector", a 16-bit number which "uniquely identifies one of 16K possible segments in a task's virtual address space" but "the selector value does not specify the segment's location in physical memory."

C programmers hated it. C was the dominant language at the time, and C programmers really hated it. This change killed the single 20-bit address space and it killed pointer arithmetic for pointers more than 64k apart. It's hard to express the degree of hate programmers had for it if you weren't there. It was a revolt - with few exceptions, programmers simply refused to program this way, instead using just the lowest 1MB of memory where they could pretend they had an 8086.

So the customers chose convenience over security, and the vendors saw this and provided exactly that. And that lesson has not been forgotten.

I never hated that memory addressing scheme - not do I remember any coworkers ever commenting on it one way or another.
Looking back on it, it was kludgy. But it was a reasonable way for Intel to extend physical memory while maintaining backward compatibility.

Separating code and data is good programming - and good programming provides fewer opportunities for security attacks.

Hardware can certainly help, but it is not the end all. In the 1980's, Data General introduced its Eclipse MV series featuring a ring system design specifically to protect the operating system from attack - intentional or otherwise. A kernel of the OS sat in ring 0, the center, most protected ring - with its own memory. Most OS Services ran out of rings 1 and 2. At outer ring could only access services from an inner ring through a gate. I think the theory was that as long as you got those gates right, an inner ring could not be broken. Within two months of working on that machine, I discovered a "System Available Memory" management bug that would allow application code to overwrite a kernel stack segment. If I wanted to intentionally hack the kernel, I could have replace kernel stack data and return addresses to redirect the kernel to whatever I wanted.

The moral of the story is that programming bugs will always present potential attack lanes - regardless of what hardware services are available. Every time you encountered a Windows blue screen, you were looking at a potential attack lane. The program was not doing what the programmer wanted it to do.

There are hardware features that can help - both directly, as with the DG ring structure or indirectly with features that make programming less complicated (like separating code and data). There have also been hardware features that have hurt - like memory caching mechanisms or device driver firmware that could not be protected by the operating system. But when the hardware holds up its end, security rests with the software.

 

[Baluncore]

The moral of the story is that programming bugs will always present potential attack lanes - regardless of what hardware services are available.

OS bugs yes, user code bugs no.

I hand punched my first programs to run on a Burroughs 6700. At the time I was naively unaware of the security provided by the Burroughs hardware, probably because no one was hacking that system's architecture, and they still don't. Later I did discover why hardware was so important, but only after I scrapped a B6800. Coding for, and servicing DG Nova and DG Eclipse RISC processors was also enlightening. Funny how you don't know what you've got till it's gone when you find yourself programming Intel based PCs.

It is interesting to see how Intel processors have gradually developed the absolute minimum hardware support needed to implement secure systems. But those features are largely ignored by system developers, except by a very few, like the Unisys ClearPath servers that are now based on Intel processors.

Many PC programmers today lack understanding of the elegant security available from a 3 bit tag field on each word, or the concept of a cactus stack, with hardware memory management.
That goes to explain why so many users today are immersed in an ocean of insecurity.

 

[.Scott]

OS bugs yes, user code bugs no.

It depends on what "user code" you are talking about.
One of the biggest security issues was created about 7 years ago by a zero-day Adobe bug. But if you Google this, you may have trouble because there was another zero-day Adobe bug just last year.
How can the OS defend against these? The Adobe application is allowed to read and write files in the application area and connect to the internet. For many exploits, that's all that's needed.
In both cases, all the user had to do was open a pdf - which would then appear to open exactly as expected.

 

[Baluncore]

It depends on what "user code" you are talking about.

Adobe is not part of the OS, it is a user application. A secure OS should prevent an application run by one user from writing to another users files.

 

[Rive]

It is interesting to see how Intel processors have gradually developed the absolute minimum hardware support needed to implement secure systems. But those features are largely ignored by system developers, except by a very few, like the Unisys ClearPath servers that are now based on Intel processors.

I think you are somewhat lost with this. The migration of that kind of thought line to x86 is just a small corner - the main section is the boom of virtualization: and if you look for security of that level, then you have to look for the supervisor software and the continuous development of x86 based high reliability 'big' servers in general.

For any personal use OS that kind of security was never even considered - most user would just switch to something lighter with less limitations right off the bat.

You are asking for the reliability of a big railroad diesel - in a small, pink colored shopping car.

Ps.: the actual personal use OS in relation to the mainframe world would not be considered much more serious than an user shell...

 

[anorlunda]

To be secure the hardware must;
1. Differentiate between executable code and data.
2. Have hardware bounds checking on virtual memory pages used for code and for data.
3. Restrict privileged instructions to the kernel of the OS.

When you compile a C source and execute it on that system

That's contradictory because the source code is data to the compiler and the object code is data to the loader, a moment later it becomes executable code. When a OS patch is transmitted it is data, the patch file or .EXE first resides in user space, then it changes the OS executable code.

I agree with your point 1. But my definition of differentiating between executable code and data means that the executables must be changed with a soldering iron. There must be no software means to penetrate the data/code barrier. I say that because the threats I fear are all remote attacks, and because all successful malware somehow manages to get evil code executed. Remote attacks can include social engineering where the authorized user is tricked into doing some compromising act.

The title perhaps should have said secure against remote attacks. I would think is self-evident that there is no defense against a local attack that specifies, designs, replaces or destroys local hardware and software.

A secure OS should prevent an application run by one user from writing to another users files.

A web cam is hijacked remotely to become part of a botnet. Who are the multiple users in that case? Is there necessarily such as thing as a user account in a IOT device? I am trying to think of security in terms broader than just PCs, or servers.

 

[Baluncore]

That's contradictory because the source code is data to the compiler and the object code is data to the loader, a moment later it becomes executable code. When a OS patch is transmitted it is data, the patch file or .EXE first resides in user space, then it changes the OS executable code.

I agree that all source code is data. The insecurity comes when the product of that data is carelessly promoted to privileged executable code, without appropriate permission.

Execution of privileged instructions that can break system security should only be permitted by a certified OS kernel of manageable size and complexity. Rogue software must be summarily terminated on any attempted breach of it's allocated resources. To be secure, a system requires a secure resource management kernel protected by hardware traps.

The single user PC today is insecure because it is too flexible, in too many ways.