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

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?

[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?

[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?

[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.