Secure Programming in GNU/Linux Systems: Part I

LNXPhreak writes "A new article on OSWeekly.com discusses secure programming in GPU/Linux systems in terms of programming talent and requirements. Quote: "A "secure program" is an application that sits on a security boundary, taking input from a source that does not have the same access rights as the program. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs."

Comments

Unsafe Languages?

[(1 -sqrt(5))*(2**-1)]

In spite of myself, I went into TFA with cautious optimism; the author lost a lot of credibility by me, however, when he averred:

C is an unsafe language, and the standard C library string functions are unsafe.

I'd counterplead (to borrow a gun-canard): languages are not unsafe, but programmers are.

Re:Unsafe Languages?

[gowen]

Well that's strictly true, but you know what he's saying.
The string handling functions of the standard C library make it very easy to write unsafe code.

Similarly, a car with very bad brakes isn't intrinsically unsafe, as long as the cautious driver is prepared to take alternative precautions on ever bend. But if the driver makes an error (and everyone, yes, even you, will eventually make an error), he's going to end up wrapped around a tree.

Even though other cars aren't safe in the hands of a bad driver, given that you will make mistakes, you'll have far fewer horrific crashes in a car with ABS.

Re:Unsafe Languages?

[A beautiful mind]

Exactly. Article writer has no knowledge in the area.

If C library functions would be unsafe then pretty much other languages would be unsafe aswell.

Yes, we all know about buffer overflows, and that stupid programmers use strcpy without bounds checking, but what more can you do that tell in the documentation explicitly to use strncpy, a new function added just to combat this problem of stupid/lazy programmers who doesn't check bounds properly.

Re:Unsafe Languages?

[Anonymous Coward]

Are you fucking kidding me? Humans aren't perfect, even uber programmers. We can either spend ten times as long with C, or we can use a modern language. Guess what most people and organizations interested in not wasting massive amounts of time and money choose.

Re:Unsafe Languages?

[Anonymous Coward]

In spite of myself, I went into TFA with cautious optimism; the author lost a lot of credibility by me, however, when he averred:

        C is an unsafe language, and the standard C library string functions are unsafe.

I'd counterplead (to borrow a gun-canard): languages are not unsafe, but programmers are.

You are wrong. C, by design, does not enforce any type of boundary checking something that many other languages do. Other languages do enforce that and are therefore, by design, safer than C. Your cliché doesn't hold - it is the same as saying "Internet Explorer isn't unsafe, users are." Besides, the quote doesn't come from the author but from the hacker Aleph One which is one of the top security expers in the world.

Re:Unsafe Languages?

[slavemowgli]

He does have a point, though. It *is* possible to use the standard C library string functions in a safe manner, but it's difficult and error-prone - and if you make just one mistake, it might well be enough to open an exploitable hole in your program.

It's important to realise that programmers aren't perfect. "unsafe" programmers, as you call them, are not something you'll ever be able to get rid of; your best bet is thus to give them tools that make it as easy as possible to write safe code and that will mitigate the impact when things *do* go wrong - in other words, tools that will fail in a defined and safe manner.

One of the problems with C (actually, one of its strengths, too, of course, depending your point of view) is that it's really only optimised for speed, and a lot of compromises were and still are made there. Similarly, another problem is that C is intended as a very low-level language - a hardware-independent macro-assembler with automatic register allocation, if you will. This makes it very suitable for certain low-level tasks (like OS kernel programming), but it also creates problems when you move higher up in the level hierarchy, away from the bare metal.

C does have its place, but if you want to develop an application that's not closely tied to the hardware etc., C probably isn't as ideal a choice as you might think - and at the very least, if you *do* decide to use it after all, you should be aware of its weaknesses and pitfalls so you can avoid them.

It's just like with guns. Guns can be handled in a safe manner, but that doesn't mean you should give everyone a loaded and unlocked gun who's never touched one before in his life - chances are that accidents *will* happen. And while you can say that it's handler's fault, not the gun's, well... accidents still will happen. It's better to get off of one's high horse and try to minimise the number of actual incidents (and the severity of those incidents that do happen), since that's what counts in the end.

Re:Unsafe Languages?

[miyako]

I completely agree with you're point, and just thought I would pose a random sort of thought I had.
The biggest problem with C and C++ is that it's very easy for novice programmers to create insecure programs because, for the most part, they don't know how to properly work with pointers. Now days it seems to me that much fewer people learn C/C++ than used to just a few years ago. In highschool in my CS pretty much everyone who knew any programming knew C or C++. Back then, and that was only a few years ago mind, it seemed rare to me to know anyone who knew, e.g. perl or Java, and didn't know C or (more often) C++.
Now, this semester I graduate with a degree in Computer Information Systems, and of the 20 or 30 people I know off hand that are within a semester or two of me, I'm the only one who is competent with C++. There are a couple of other people who vaguely know it, and could probably recognize the syntax, but couldn't write anything useful in it.
At my school, the programming languages that are explicitly required are Java, VB.NET, COBOL, and just enough C# to do some stuff in ASP.NET- which is required for the web class. They teach a couple of assembly classes, and a couple of C++ classes that are required for the CET majors and offered as an elective to the CIS majors. I'm the *ONLY* person in the 4 years I've been at school I know who is a CIS major who took these classes.
So now, a lot of people who call themselves programmers are graduating and, quite literally, have no idea what a pointer is. So, this makes me wonder. Are C and C++ safer because most of the bad programmers are now working in "safe" languages like Java, or are they less safe because people don't learn about pointers early on?
Personally, I never understood why people have such trouble with understanding pointers, but then it may be because in highschool I was lucky enough to have an absolutely fantastic computer science teacher who instilled the basic ideas in us about how the compiler works and how variables work, and what memory addresses are, etc. from our first programming class.
Anyway, there wasn't much of a point to all that (it's 4:20am right now, and I should have been in bed 4 or 5 hours ago, so just be thankful that it's coherent (if indeed it is)) but maybe it'll stimulate discussion anyway.

Re:Unsafe Languages?

[KiloByte]

We can either spend ten times as long with C, or we can use a modern language.

What do you call a modern language?

I do trust code in C a lot more than those written in C++, as from my experience the former tends to break less. This is just an intuitive feeling.

About Python, I prefer to not touch anything written in it with a ten-foot pole. For me, it's enough to take a look at code written by, obviously very skilled, programmers:

* apt-listchanges
If you interrupt it (Ctrl-C), it breaks noisily, spewing a screenful of its innards right in your face, instead of accepting SIGINT like any good behaving Unix program is expected to. Hint: the proper behaviour doesn't take any code in most languages.

* btdownloadheadless/btdownloadcurses
When you try to quit them, they give an error message and hang for several minutes, ignoring all signals they can.

* Xen
The VM daemon either hangs or dumps data on the floor wherever an error occurs. Trying to shutdown a SMP guest which has no CONFIG_HOTPLUG_CPU? Hang. Trying to save a VM when there is not enough disk space in dom0? Data loss. Some idiot (well, me) upgrading Xen sshed outside->a domU->dom0? Massive data loss. Shutting down the dom0? Hang.

It probably isn't a wise thing to judge a language over just a few bad experiences. Yet, out of 3 programs written in Python that I use, 3 are extremely flaky, even though they are written by people known to be very competent. So, I unconsciously do anything I can to avoid Python, even though I have no "rational" reasons.

Re:Unsafe Languages?

[EsbenMoseHansen]

Actually, strncpy is almost as bad as strcpy, with the added bonus of being inefficient. Use strlcpy. strncpy is a leftover from an early database format, and should almost never be used.

Re:Unsafe Languages?

[UlfJack]

How good a programmer are you? Good? Very good? Excellent? Even Perfect?

No doubt you are not perfect, you are human after all. Now, I've never seen a Java programmer write code that could be exploited with a buffer overflow exploit. But I've seen countless buffer overflow bugs in C software. Just subscribe to one of the numerous security mailing lists.

Yes, you can write unsafe software in Java. No doubt about that. But a language where you cannot use the standard library (string functions!!!) for security related software is at best not well designed.

Re:Unsafe Languages?

[4D6963]

I never understood why people have such trouble with understanding pointers

I've been both in the position of one of the students who had the thougest times understanding pointers in Pascal, and when I started skipping college and studying C at home I started understanding them really well.

Personally, what prevented me from understanding them back when I was in college was their nature, I didn't understand how it worked. When I started working with C and with heavily sending and returning arrays and values from functions, it only made sense to me when I understood that a pointer was an address, and that for example when you want to send a variable to a function and make it modify it, you have to send its address so the function doesn't have to return a value, but can modify the contents of the indicated address.

Once I understood that pointers suddenly went from mysterious to easy and actually people who tell me about pointers when I say I program in C tell me shit like "so you like pointers, huh?" well I actually do now. I think that pointers are only hard to understand (at least in my case) when the language you're in tries to make abstraction of what a pointer really is (like Pascal) as I think one of the strength of C is that it acts more closely to the reality of how things really get done (in a fashion closer to assembly code, although it's portable) and thus makes it alot clearer. (Disclaimer : I've only been doing C for about a year and most of what I work on is DSP programs, thus I rarely have to deal with strings, otherwise I wouldn't like C that much)

Re:Unsafe Languages?

[Anonymous Coward]

Yep. strncpy() only null-terminates the string if the null-character fits in the buffer. In addition, it null-pads the entire buffer, which can lead to horrible performance.

Use strlcpy().

Re:Unsafe Languages?

[Anonymous Coward]

Well in that case, PHP must be the most unsafe language ever made...

Anyways... does that mean that good programmers should use C, and bad programmers something else (like java or python)?

Re:Unsafe Languages?

[gowen]

No, it means good programmers can use any language they like, but there'd better be a good reason for using C and "I'm such a good programmer I never make mistakes" isn't a particularly good (or honest) reason.

And yes, bad programmers should avoid C like the plague.
Because of unchecked pointer dereferencing and the lack of array bounds checking, there are very few bugs in C code that can't become security holes. Sandboxing is good, and C makes sandboxing very hard work. It's a buffer overflow waiting to happen.

Re:Unsafe Languages?

[AVee]

languages are not unsafe, but programmers are.

Yeah, great one-liner. Now tell me, these languages are created by who again?
When you feel software should be developed with security in mind, surely the same applies to programming languages. Fancy sound-bites like that are as insightfull as saying "It's the drivers who are dangerous, not they car." while removing the seatbelts. Sure, you're right and likely to be 'dead right' soon.

Re:Unsafe Languages?

[AVee]

...but what more can you do that tell in the documentation explicitly to use strncpy...

Well, remove or fix strcpy perhaps. In other words, develop a safer programming language...

Re:Unsafe Languages?

[master_p]

Actually, you are wrong: a programming language is as unsafe as the most "unsafe" programmer of a project is. In other words, you may have a team of C experts that write the most secure C, but it only takes one minor error from a not-so-experienced programmer or from an experienced programmer in a bad day to bring down whole systems.

So although your argument seems correct on the surface, it actually is not true: a programming language shall enforce safety.

Re:Unsafe Languages?

[WillerZ]

Are C and C++ safer because most of the bad programmers are now working in "safe" languages like Java

Yes. I think that's a lot of the reason.

Anyone who's still writing C probably has enough experience to know the pitfalls. All the johnny-come-latelies are writing Java, C# or scripts.

Re:Unsafe Languages?

[Anonymous Coward]

Anyone who's still writing C probably has enough experience to know the pitfalls.

Yeah, and I'm the Queen of England.

I still see plenty of C code that I wonder how the hell it was written by an experienced programmer, but it was.

Re:Unsafe Languages?

[squiggleslash]

The GP didn't mention Python.

Personally I think he's wrong but not for the reasons you mention. What's needed is a "managed" language, not a "modern" language. Managed languages have existed almost since high level languages were invented, indeed, for the most part, we did a bad (if necessary at the time) thing during the late sixties to the mid-nineties when languages started to allow us to do unmanaged things.

Examples of managed languages include Java and C#, Pascal and the Modula series of languages (and Oberon, I guess), not to mention a great many interpreted languages like Python (as you mentioned), BASIC, LISP and its derivatives, SmallTalk, et al.

The first group of languages has performance comparable to C, C++, and Objective C. Some are cruder than others ("classic" Pascal is a PITA to work with, mainstream 1980s versions had to massively extend it to get it to work, frequently ending up discarding management along the way), others, like Java, currently suffer from the way they're currently packaged (but see GCJ), but all essentially prevent you from making basic mistakes and provide a level of code security that, arguably, makes hardware memory protection obsolete.

I'm not going to argue they're perfect. Java suffers from its designers obsessions with discouraging the use of native APIs in the name of half-arsed "portability", and both it and C# require substantial run-times for much the same reason. At the same time, when you use either, the level of security you get is much, much, better, with it being much more difficult for a bug in one piece of code to corrupt another in an exploitable way.

I love C, I really do. I've programmed it since the late eighties. I've amazed myself with some of the stuff I've done. But, with hindsight, while we probably couldn't have gotten here today without the experimentation and lack of restrictions it did for us, it's also the case we've had to end up with vastly inefficient computer and operating system designs and our current problems with security are manifested in our decisions to base our entire computer infrastructures on that language. Much as I hated it at University, with hindsight I think Modula 2 and its object oriented successors would have been a better choice. And now that Java and C# have momentum, it's time to jump on board with both feet.

Re:Unsafe Languages?

[Kjella]

Consider C/C++ something like downhill skis. If you know what you're doing, you can go incredibly fast on racing skis. Hell, you'd be pretty quick on normal skies too but that translates well to novice/pro programmers.

But if you don't know what you're doing, you are a lot more likely to hurt yourself badly on racing skis. Why? Because they're only designed to give you the minimum of control you need to get down in one piece. They will not forgive you the slightest mistake, instead you will crash.

So to if a newbies comes in thinking he'll buy racing stuff because they're so flashy and cool and expensive (and he's got the cash), if you have any conscience you'll advice against it. You'll tell him that using this equipment is unsafe.

C/C++ pointers work the same. Most of the time you don't need that extra bit of speed, 99% of the time it's just about reaching the goal. 99% of the time you're just being unnecessarily unsafe. Personally I wrap most things in a library instead of using another language, I don't deal with zero-termination or buffer overflows.

If that really gives inadequate performance, try redesigning what you're trying to do or the method you're doing it with. Dancing around with pointer arithmetic instead of wrapper classes with offset checks is really a last-ditch resort for me, right before I would seek someone who knows assembler.

Re:Unsafe Languages?

[the chao goes mu]

One objection: What if one of your "unsafe" programmers wrote the interpreter or compiler for your "safe" language (eg. a buggy JVM)? Then you have no security, errors, and no way to fix them as the error is in the interpreter, or compiler, and not in the code itself. C may allow bad code, but it allows me to directly fix that bad code without much difficulty. (And yes, by the same argument, assembly is even better, but I have yet to convince my boss of that the way I have about C.)

Re:Unsafe Languages?

[zootm]

Strictly the distinction usually made between "safe" and "unsafe" languages is the number of things that can be detected at compile-time, rather than runtime. There are whole classes of errors which, in modern "safe" languages, just cannot happen, if the program compiles. This verifiability means that more potential problems are spotted before the code is run, and obviously, the earlier these things are caught, the better. People often complain that there is a loss of direct "power" from such things, and to a degree they're right.

But C allows you to directly manipulate pointers to memory. This operation is deemed unsafe because it's not possible to systematically verify that that memory will behave the way that you anticipate. It allows you to (easily) take advantage of language implementation issues that should not be exposed to the programmer, let alone used.

It's not generally a strict term (the CLI gives it a strict meaning, but that's basically restricted to the CLI), but in general, although unsafe programmers exist all over the place, there's not a single 100% safe programmer in the world. We all make mistakes, and making languages which catch more of these at as early a stage as possible can only be a good thing. If you have a specific reason not to use them, that's usually fair enough, but this doesn't mean that they're not better for tasks where there's not a need for the higher degree of control available from these "unsafe" languages.

Re:Unsafe Languages?

[LearnToSpell]

So that's what you do all day! And here I thought it was just crumpets and polo matches.

Re:Unsafe Languages?

[mrsbrisby]

The string handling functions of the standard C library make it very easy to write unsafe code.

So what?

Secure programming in C tends to avoid using the string handling functions as provided by ANSI and POSIX.

Secure programming in C++ tends to avoid IOS for loss of atomicity.

Secure programming in Perl tends to avoid iterpolation of user-data.

Secure programming in any language tends to involve avoiding the mechanisms that are difficult to verify correctness with.

Indeed: the most secure programming languages are the ones where correctness is easiest to verify- to do so in Java or Perl means verifying the VM and runtime, and to do so in C++ means finding that rare soul that actually understands what kind of nonsense the compiler is doing behind your back.

That is to say that C is one of the best languages to use for secure software- not the worst- simply because it's easier to verify correctness on the whole, than with other languages and runtimes.

The example of the image viewer that reads from an untrustworthy source is an excellent one- the Image viewer can be written in any language they like- and could have dozens of bugs and still not be a security risk if the application were run with a restricted uid and had no file or network I/O access.

This could be done by splitting the application into several parts- one that represents the file I/O, one that represents decoding, and one that blits to the screen. The part that represents decoding is probably the hardest to verify, so it would be limited to pure CPU operations, reading bits from an existing pipe (from the file I/O part) and writing bits out to another existing pipe (representing the blitter).

This approach works well, and believe it or not, in a world of increasingly multi-core and multi-processor systems, it's actually faster.

Re:Unsafe Languages?

[mrsbrisby]

It *is* possible to use the standard C library string functions in a safe manner, but it's difficult and error-prone - and if you make just one mistake, it might well be enough to open an exploitable hole in your program.

That's why isolation is so important. It's not easy, or taught often how to isolate and privilege separate code. As a result, people don't do it.

With isolation the programmer can actively ignore bugs like this and concentrate on other things knowing full well that any bugs there aren't going to turn into security holes.

if you *do* decide to use it after all, you should be aware of its weaknesses and pitfalls so you can avoid them.

You should be aware of all the things your language-of-choice is weak at.

You should also be aware that security is about proving resistance. This is very difficult to do in a managed environment (do you trust your VM?) or when the compiler does things behind your back.

As a result, C is often a better choice for experienced programmers because it is harder to make a bad C compiler than a bad compiler for [most] other languages- including C++- and as a result, there's simply less code to verify in C, than with other languages.

I use C primarily for isolation machinary- simply because that stuff isn't available in other languages- or is harder to get at. As a result, I can write the meat (read: insecure/buggy parts) in other languages as I like, knowing that even if I allow remote code execution to occur in those parts, it still doesn't constitute a security hole.

Re:Unsafe Languages?

[try_anything]

Exactly. Article writer has no knowledge in the area.

Or perhaps you're missing the point.

The article writer isn't saying that a smart, conscientious C programmer can't copy strings correctly 98% of the time. He's saying it isn't good enough to meet that standard, and most languages do better. Even C++ allows you to simply write string s2 = s1.

To do the same thing in C, the programmer must know or check the length of s1, know or check the length of s2 (actually, know or check whether s2 points to any memory at all), possibly reallocate memory for s2, and copy exactly the right number of characters from s1 to s2. There are many possibilities for a typo or a lack of caffeine to open a security hole.

this problem of stupid/lazy programmer

No one denies that requiring several lines of finicky code to perform a simple operation separates the mental weenies from mental he-men. If your ego is the biggest thing on the line when you create software, by all means, keep using C for everything.

Re:Unsafe Languages?

[Anonymous Coward]

I would contend that C is optimized for control, not speed, which happens to mean higher speed in many cases because you have it doing fewer unnecessary steps. There are fairly simple areas where you are not guaranteed to get optimal results on all architectures which could theoretically be fixed in a language optimized for speed by asking for more information from the programmer. For instance, there was an interesting article I read about how - on certain architectures - branching based on what range a number falls within proves to be more efficient as a linear search than a binary one up to a surprisingly high number of branches because of the large penalties of failed branch prediction. This would, of course, be platform dependent. The switch statement is, of course, something of a nod in this direction, but is quite rigid and necessarily assumes an even distribution in it's optimization calculations. If it were really speed that was being optimized, this kind of thing would be taken care of in the compiler, after the programmer specifies the expected distribution of input to the particular statement.

Re:Unsafe Languages?

[ufnoise]

C is an unsafe language, and the standard C library string functions are unsafe.

"Secure Programming Cookbook for C and C++ : Recipes for Cryptography, Authentication, Input Validation & More"
by John Viega, Matt Messier.

This is an excellent book which discusses many of the issues with writing safe code. They present safe versions of many of the standard C library functions.

In addition, the C++ STL string classes are very well written for doing string handling in a safe manner.

Re:Unsafe Languages?

[kbielefe]

I'm the *ONLY* person in the 4 years I've been at school I know who is a CIS major who took these classes.

Not that it will help you now, but that's a clue that you're in the wrong major or possibly the wrong school for your aptitude. I'm not saying there's anything wrong with your major or school, just that you personally may have been happier somewhere else.

People don't understand pointers because they are extraneous to the understanding of algorithms. You only need to know the address of a variable when you are writing something like a device driver or a compiler. Of all the programming languages you mentioned, I believe C/C++ is the only one where pointers are a commonplace concern for the programmer (don't know about cobol).

It is not pointers that intrinsically make C/C++ unsafe. Pointers are an unavoidable part of software, even though they are usually avoidable by the programmer. In fact, internally a Java program will use many more pointers than the equivalent program in C.

What makes C unsafe is that programmers constantly must reimplement potentially unsafe code to fit different situations. You'll find that your coworkers will have approximately the same mix of talent as your classmates did, but even highly talented and experienced engineers make trivial mistakes in pointer code sometimes. Compare this to a language like Java or Ada which implements that dangerous code only once inside the compiler, usually by the best programmers on a team, taking unsafe pointer conditions as a primary design concern, and then reuses that hardened and highly scrutinized code everywhere.

Re:Unsafe Languages?

[Nevyn]

He does have a point, though. It *is* possible to use the standard C library string functions in a safe manner

It's possible for non-trivial applications? Can you provide an example then? I can provide a few examples that basically never use the std. str* functions, and are considered safe by their authors.

Saying C itself is unsafe, can be argued against (although what they generally mean is things like the apache-httpd malloc() attack are possible, while they aren't in Java -- although, again, that was inside a crappy str* string helper so would have gone away if apache-httpd used a half decent string API).

Re:Unsafe Languages?

[Anonymous Coward]

But C allows you to directly manipulate pointers to memory. This operation is deemed unsafe because it's not possible to systematically verify that that memory will behave the way that you anticipate.

What? What kind of OS do you run where memory doesn't behave the way programmers should anticipate?

Windows, maybe?

Re:Unsafe Languages?

[miyako]

Not that it will help you now, but that's a clue that you're in the wrong major or possibly the wrong school for your aptitude. I'm not saying there's anything wrong with your major or school, just that you personally may have been happier somewhere else.
Yeah, this was something that I realized, unfortunately to lately to reasonably consider being able to change majors without going to school an extra few years. It's not specifically that I dislike CIS, I am infact fairly skilled with systems analysis and CIS disiplines, but in the end my true heart lies with CS. I enjoy messing about with compilers and OSes in my spare time, as well as more abstract CS problems. My plan is to try to find work, and possibly go back for a second degree in computer science in a few years.

Re:Unsafe Languages?

[zootm]

Any efficient operating system. There's a lot of allowances in some implementations of some of these languages for completely false assumptions.

Re:Unsafe Languages?

[Jaqui]

The real issue isn't the languages, it is the people doing the coding.

It doesn't matter what language, or even what section of a language is not well designed,
if the person doing the coding pays little or no attention to keeping it secure, then
the application will not be secure.

The coders are the ones responsible for all issues with the program(s), not the language
it was written in.

One language were the majority of coders make the same HUGE error, is JAVA. they code
for a specific jre, which will probably conflict with one of the 12 jre's installed to
be able to use another such program.
[ This lack of compatability in runtime environments for java is why I do not use any java apps. ]

Re:Unsafe Languages?

[Anonymous Coward]

You should also be aware that security is about proving resistance. This is very difficult to do in a managed environment (do you trust your VM?) or when the compiler does things behind your back.

I disagree with you. Security is simply about building secure systems. Although formal proof can play a significant role in verification, it can become extremely unwieldy with complex systems, and I'm a skeptical of your implication that it's easy to do in an unmanaged environment.

I think it's much more important to write programs in such a way that they are probably secure and structure systems such that insecure programs have a limited impact on overall system security. I agree with you that privilege separation certainly helps with overall system security. However, managed code definitely helps write "probably secure" software since the answer to the question "do you trust the VM" is almost always "at least as much as everything else."

Re:Unsafe Languages?

[dodobh]

The Java programmer just allows SQL injection. Your data is still toast.

Not validating input is the error in both cases.

MOD PARENT INDEED!

[Anonymous Coward]

Mod parent indeed (that's +5).

Vizzini Logic

[Anonymous Coward]

FTFA: -Programmers are human, and humans are lazy. Thus, programmers will often use the "easy'' approach instead of a secure approach, and once it works, they often fail to fix it later.

...But, you've also bested my Spaniard, which means you must have studied, and in studying you must have learned that man is mortal, so you would have put the poison as far from yourself as possible, so I can clearly not choose the wine in front of me.

Janitors need training/education

[Anonymous Coward]

Posted by CowboyNeal on Friday March 31, @04:20AM
from the better-safe-than-sorry dept.

LNXPhreak writes "A new article on OSWeekly.com discusses secure programming in GPU/Linux systems in terms of programming talent and requirements. Quote: "A "secure program" is an application that sits on a security boundary, taking input from a source that does not have the same access rights as the program. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs."

GPU/Linux eh? Way to go, "editors".

Re:Janitors need training/education

[Solra Bizna]

Clearly, a variety of Linux tailored to drive some state-of-the-art software-controlled video card. :P

-:sigma.SB

Re:Janitors need training/education

[Anonymous Coward]

GPU/Linux

Sweet! Finally, we'll get some non-beeping diagnostic messages during POST. booting Linux 2.6.xx on GPU0 ... and so on.

What say you, cowboy? a typo? bummer! Oh well, don't give up yet, we'll Neal it some other time then.

Rule 1

[poeidon1]

Avoid programming in C as much as possible.

Re:Rule 1

[Anonymous Coward]

Why?

Re:Rule 1

[Anonymous Coward]

in that case, Since the operating system makes or breaks the security model, it's best to avoid all operating systems written in C.

Re:Rule 1

[Anonymous Coward]

C is not dead, in fact it is VERY useful:

1. kernel code
2. embedded systems with limited capabilties (small memory, slow, etc.)
3. tight, verifyable code (you can easily view the assembler)
4. libraries
5. hardware interfaces
6. extensions of existing applications in C (Gnome, asterisk, etc.)

Re:Rule 1

[DrSkwid]

well, people *have* tried

http://plg.uwaterloo.ca/~glmclear/research/perlos/

Re:Rule 1

[NNland]

If you are going to go with a P-language OS, why not go with http://www.unununium.org/ ?

Re:Rule 1

[DrSkwid]

I like the look of that.

I knew there was a reason to own an AMD64 X2

thanks

As a side note...

[sgant]

Does anyone other than Richard Stallman really call it GNU/Linux? How come you never hear of GNU/FreeBSD? I mean there are a ton of GNU applications also on BSD right?

Just wondering....

Re:As a side note...

[macshit]

Does anyone other than Richard Stallman really call it GNU/Linux?

Yes.

It's largely a matter of which community you hang out in; some places everybody calls it GNU/Linux (in large part out of respect for the FSF as far as I can tell), some places they flame you to a crisp for even suggesting it.

It doesn't really matter; call it what you want, people will know what you mean.

[A special case is if you are involved in a discussion with RMS: you're probably better off saying GNU/Linux (in the discussion), because if you don't he'll pester you tirelessly until you do. If you really want to get on with the real subject, it's simply not worth the effort to fight it...]

Re:As a side note...

[Anonymous Coward]

Does anyone other than Richard Stallman really call it GNU/Linux? How come you never hear of GNU/FreeBSD? I mean there are a ton of GNU applications also on BSD right?

AFAICS, GNU/Linux is fair because the C library - which is also pretty core to the system - is GNU's. Ditto other important libraries like ld.so which are all part of the glibc package. The core unix utils are all GNUs too but they're not as fundamental to the system as the libraries.

By comparison FreeBSD have their own BSD basic libraries and core unix utils - yes, the GNU tools do run on them but they're not an essential part of the system.

Not that I call it GNU/Linux myself though.

Secure Programming...

[ltning]

...in GNU/Linux systems: 1500 pages, 3 volumes. ...in Windows systems: Two words: "You don't".

Clash of the Cliches ...

[Zero__Kelvin]

Actually, C is an unsafe language, and guns are dangerous, even in the right hands. The definition of "The Right Hands(tm)" is: "Someone who knows how intrinsically dangerous they are by nature."

While we are throwing cliches around, I will toss this one out there: "The right tool for the right job."

You wouldn't want to protect yourself from an attacker with a sponge, even though they are soft and fuzzy and safe. You wouldn't want to go deer hunting with a compiler. The problem is this: A gun in the hands of a person who doesn't understand why people think they are dangerous, is very dangerous!

C is not a safe language ... it is a powerful one. One can write secure code with C, just as one can shoot oneself in the foot with it. You significantly minimize the risk of shooting yourself in the foot when you take a course that helps you understand how and why the gun is dangerous, and the methods you can use to mitigate the risk.

Here is the problem, though: You don't need a C permit to write code using the C language." As a result, there are far too many people out there haphazardly swinging the barrel of their C compiler around thinking C saftey is a matter of pointers. You can be as careful as you want about where you point your gun when it is in your hands, but if you believe that gun safety begins and ends there, someone is more than likely going to get hurt. It is not enough to be careful where you point your C compilers barrel. You need to lock it up when you are not using it ....

Re:Clash of the Cliches ...

[mrsbrisby]

C is not a safe language ... it is a powerful one.

I'd like to take that a point further- there aren't any safe languages.

It's just a whole lot easier to be safe with C because all the machinary is simple, than it is with other languages- that are a lot more complicated (and have more placed for shit to clog something up and blow your face off).

Unsafe languages (and implementation details)

[joel.neely]

The use of unconstrained pointers and casting (don't forget that in C this includes arrays!), combined with allocation of local data in the same stack that contains state information (registers to be restored upon function return) is at the heart of a large portion (most?) of the common security vulnerabilities on PCs.

Some large-ish number of years ago I saw an article in which the author (don't recall the name offhand, sorry) asserted that raw pointers were the data equivalent of GOTOs. Both are potentially useful as under-the-hood implementation mechanisms, but entirely too easy to abuse for them to be exposed in a high-level-language.

GPU/Linux?

[ignorant_newbie]

Did someone get Linux to run on a graphics card now? damn.

Re:GPU/Linux?

[tetabiate]

Imagine a beowulf cluster of ... never mind!

Avoid programming in PHP as much as possible

[Anonymous Coward]

PHP is the worst language I have ever used, from a security perspective. Scan the security lists for the programs that have the most problems -- they ain't C programs.

"not they car"?

[Anonymous Coward]

WTF does that mean?

Re:"not they car"?

[Anonymous Coward]

It sounds like somebody set up us the bomb.

Re:Help vandalize Wikipedia.

[Anonymous Coward]

you fucking tard
just because something isn't perfect doesn't mean it needs to be torn down
get off my internet