Secure Programming in GNU/Linux Systems: Part I 64
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."
Unsafe Languages? (Score:3, Insightful)
Re:Unsafe Languages? (Score:5, Insightful)
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? (Score:1)
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
Re:Unsafe Languages? (Score:3, Interesting)
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 a
Re:Unsafe Languages? (Score:2)
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? (Score:4, Informative)
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? (Score:2, Informative)
Use strlcpy().
Re:Unsafe Languages? (Score:2)
Well, remove or fix strcpy perhaps. In other words, develop a safer programming language...
Re:Unsafe Languages? (Score:3, Insightful)
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 memor
Re:Unsafe Languages? (Score:2)
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 sc
Re: (Score:3, Interesting)
Re:Unsafe Languages? (Score:1, Insightful)
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 t
Re:Unsafe Languages? (Score:5, Insightful)
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? (Score:2)
Re:Unsafe Languages? (Score:2)
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 goin
Re:Unsafe Languages? (Score:2)
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.org], 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, tha
Re:Unsafe Languages? (Score:5, Insightful)
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? (Score:2, Interesting)
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
Re:Unsafe Languages? (Score:2)
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? (Score:1, Insightful)
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? (Score:2)
Re:Unsafe Languages? (Score:2)
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
Re:Unsafe Languages? (Score:2)
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 an
Re:Unsafe Languages? (Score:2, Insightful)
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 r
Re:Unsafe Languages? (Score:2)
Not validating input is the error in both cases.
As a side note... (Score:2)
Just wondering....
Re:As a side note... (Score:2)
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
Re:Unsafe Languages? (Score:2)
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.
Clash of the Cliches ... (Score:4, Insightful)
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
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 ... (Score:2)
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).
Re:Unsafe Languages? (Score:3, Insightful)
So although your argument seems correct on the surface, it actually is not true: a programming language shall enforce safety.
Unsafe languages (and implementation details) (Score:5, Insightful)
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.
Re:Unsafe Languages? (Score:3, Interesting)
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
Re:Unsafe Languages? (Score:3, Informative)
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
Re:Unsafe Languages? (Score:2)
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? (Score:2, Informative)
"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? (Score:1)
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 co
Re:Janitors need training/education (Score:2, Funny)
Clearly, a variety of Linux tailored to drive some state-of-the-art software-controlled video card. :P
-:sigma.SB
Re:Rule 1 (Score:3, Interesting)
http://plg.uwaterloo.ca/~glmclear/research/perlos
Re:Rule 1 (Score:1)
Re:Rule 1 (Score:2)
I knew there was a reason to own an AMD64 X2
thanks
Secure Programming... (Score:5, Funny)
GPU/Linux? (Score:2)
Re:GPU/Linux? (Score:1)