Security recommendations
+ There are many security problems to worry about. If you are not absolutely sure of what you are doing please request help from the ports mailing list. + +-
+
- Do
not use alpha or beta code when preparing a port. Use the + latest regular or patch release. + - Any software to be installed as a server should be scanned
for buffer overflows, especially unsafe use of
strcat/strcpy/strcmp/sprintf. In general,sprintfshould be replaced withsnprintf. - - Be sure to add the
$OpenBSD$CVS tag to - the Makefile. If importing a port from another system be sure to - leave their tag in the Makefile, too. However, replace the FreeBSD -$Id$tag with the -$FreeBSD$tag. - - Do NOT use alpha or beta code when preparing a port. Use the - latest regular or patch release. -
- The goal is to get all ported applications to support OpenBSD. To - achieve this goal you MUST feed any OpenBSD patches back to the - application maintainer. + +
- Never use filenames when you need security. There are numerous race
+ conditions where you don't have proper control. For instance, an attacker
+ who already has user privileges on your machines may replace files in
+
/tmpwith symbolic links to more strategic files, such as +/etc/passwd. For instance, the bsd linker warns about +mktempuses. These must be fixed. + This is not quite as simple ass/mktemp/mkstemp/g. + + - Just because you can read it doesn't mean you should. A well-known hole
+ of this nature was the
startxproblem. As a setuid program, + you could launch startx with any file as a script. If the file was not + a valid shell script, a syntax error message would follow, along with the + first line of the offending file, without any further permission check. + Pretty handy to grab the first line of a shadow passwd file, considering + these often start with root entry. Once again, don't trust filenames: + open your file, and do anfstaton the open descriptor to + check the actual rights. + + - Don't use anything that forks a shell in setuid programs before dropping
+ your privileges. This includes
popenandsystem. + Usefork,pipeandexecveinstead. + + - Pass open descriptors instead of filenames to other programs to avoid race
+ conditions. Even if a program does not accept file descriptors, you can
+ still use
/dev/fd/0. + + - Access rights are attached to file descriptors. If you need setuid rights + to open a file, open that file, then drop your privileges. You can still + access the open descriptor, but you have less to worry about. This is + double-edged: even after dropping privileges, you should still watch out + for those descriptors. + +
- Avoid root setuid as much as you can. Basically, root can do anything,
+ but root rights are very rarely needed, except maybe to create socket ports with
+ a number under 1024. It is arguably better to keep that under
inetd+ control and just add the relevant entries toinetd.conf. + You must know the appropriate magic for writing daemons to achieve that. + It could be argued that you have no business writing setuid programs if you don't + know how to do that. + + - Use setgid instead of setuid. Apart from those specific files needed by setgid
+ programs, most files are not group-writable. Hence, a security problem in a setgid
+ program won't compromise your system as much: with only group rights, the worst
+ an intruder will be able to do is hack a games score table or some such.
+ See the
xkoboport for an instance of such a change. + + - Don't trust group-writable files. Even though they are audited, setgid programs + are not perceived as important potential security holes. Hence stuff they can tamper + with shouldn't be considered sensitive information. + +
- Don't trust your environment ! This involves simple things such as your
PATH+ (never usesystemwith an unqualified name), but also more subtle items + such as your locale, timezone, termcap, and so on. Be aware of transitivity: even though you're + taking full precautions, programs you call directly won't necessarily. Never + usesystemin privileged programs, build your command line, a controlled environment, + and callexecvpdirectly. Theperlsecman page is a good tutorial on + such problems. + + - Never used setuid shell-scripts. These are inherently insecure. Wrap them into some C code + that ensures a proper environment. On the other hand, OpenBSD features secure perl scripts. + +
- Beware the dynamic loader. If you are running setuid, it will only use trusted libraries + that were scanned with ldconfig. Setgid is not enough. + +
- Dynamic libraries are tricky. C++ code sets a similar problem. Basically, libraries may take
+ some action based upon your environment before your main program even gets to check its setuid
+ status. OpenBSD
issetugidaddresses this problem, from the library writer point + of view. Don't try to port libraries unless you understand this issue thoroughly.
Generic porting hints
+-
+
__OpenBSD__should be used sparingly, if at all. + Constructs that look like ++ #if defined(__NetBSD__) || defined(__FreeBSD__) +
+ are often inappropriate. Don't add blindly__OpenBSD__+ to it. Instead, try to figure out what's going on, and what actual + feature is needed. Manual pages are often useful, as they include + historic comments, stating when a particular feature was incorporated + into BSD. Checking the numeric value ofBSDagainst known + releases is often the right way. See + the NetBSD package guide + for more information. +- Defining
BSDis a bad idea. Try to includesys/param.h. + This not only definesBSD, it also gives it a proper value. + The right code fragment should look like: ++ #if (defined(__unix__) || defined(unix)) && !defined(USG) + #include <sys/param.h> + #endif +
+ - Test for features, not for specific OSes. In the long run, it is much
+ better to test whether
tcgetattrworks than whether you're running + under BSD 4.3 or later, or SystemVR4. These kind of tests just confuse the + issue. The way to go about it is, for instance, to test for one particular + system, set up a slew ofHAVE_TCGETATTRdefines, then proceed to + the next system. This technique separates features tests from specific OSes. + In a hurry, another porter can just add the whole set of-DHAVE_XXX+ defines to the Makefile. One may also write or add to a configure script to check for + that feature and add it automatically. As an example not to follow, check nethack 3.2.2 + source: it assumes loads of things based on the system type. Most of these assumptions + are obsolete and no longer reflect reality: POSIX functions are more useful than older + BSD versus SystemV differences, to the point that some traditional bsd functions are + now only supported through compatibility libraries. + + - Avoid include files that include other includes that... First, because + this is inefficient. Your project will end up including a file that includes + everything. Also, because it makes some problems difficult to correct. It + becomes harder to not include one particular file at a given point. + +
- Avoid bizarre macro tricks. Undefining a macro that was defined by a
+ header file is a bad idea. Defining macros to get some specific behavior
+ from an include file is also a bad idea: compilation modes should be global.
+ If you want POSIX behavior, say so, and
#define POSIX_C_SOURCE+ throughout the whole project, not when you feel like it. + + - Don't ever write system function prototypes. All modern systems,
+ OpenBSD included, have a standard location for these prototypes. Likely
+ places include
unistd.h,fcntl.hortermios.h. + The man page frequently states where the prototype lies. You might need + another slew ofHAVE_XXXmacros to procure the right file. + Don't worry about including the same file twice, include files have guards + that prevent all kinds of nastiness.
+ If some broken system needs you to write the prototype, don't impose + on all other systems. Roll-your-own prototypes will break because they may + use types that are equivalent on your system, but are not portable to other + systems (unsigned longinstead ofsize_t), or get some +conststatus wrong. Also, some compilers, such as OpenBSD's own gcc, + are able to do a better job with some very frequent functions such as +strlenif you include the right header file. + + - Don't use the name of a standard system function for anything else.
+ If you want to write your own function, give it its own name, and call that
+ function everywhere. If you wish to revert to the default system function,
+ you just need to comment your code out, and define your own name to the
+ system function. Don't do it the other way round. Code should look like this
+
+ /* prototype part */ + #ifdef USE_OWN_GCVT + char *foo_gcvt(double number, size_t ndigit, char *buf); + #else + /* include correct file */ + #include <stdlib.h> + /* use system function */ + #define foo_gcvt gcvt + #endif + + /* definition part */ + #ifdef USE_OWN_GCVT + char *foo_gcvt(double number, size_t ndigit, char *buf) + { + /* proper definition */ + } + + /* typical use */ + s = foo_gcvt(n, 15, b); ++
Other Helpful Hints
- Do not assume
/usr/local/binor @@ -101,10 +267,35 @@ncurses.h ==> curses.h
-lncurses ==> -lcurses
``Old curses'' is available asocurses.h/libocurses. + - In OpenBSD, terminal discipline has been upgraded from the older
sgtty+ standard BSDfcntlto the newer POSIXtcgetattrfamily. + Avoid the older style in new code. Some code may definetcgetattr+ to be a synonym for the olderfcntl, but this is at best a stopgap + measure on OpenBSD. Thextermsource code is a very good example of + what not to do. + Try to get your system functionality right: you want a type that remembers + the state of your terminal (possible typedef), you want a function that + extracts the current state, and a function that sets the new state. + Functions that modify this state are more difficult, as they tend to vary + depending upon the system. Also, don't forget that you will have to handle + cases where you are not connected to the terminal, and that you need to + handle signals: not only termination, but also getting put in the background + you should leave your terminal in a sane state. Do your tests under an + older shell, such as sh, which does not reset the terminal in any way at + program's termination. + - The newer termcap and curses, as included with OpenBSD, include standard sequences
+ for controlling color terminals. You should use these if possible, reverting
+ to standard ANSI color sequences on other systems. However, some terminal descriptions
+ have not been updated yet, and you may need to be able to specify these sequences manually.
+ This is the way vim5.1 handles it. This is not strictly necessary. Except for privileged
+ programs, it is generally possible to override a termcap definition through the
+
TERMCAPvariable and get it to work properly. + - Signal semantics are tricky, and vary from one system to another. Use
sigaction+ to ensure a specific semantics, along with other system calls referenced in its manpage.
www@openbsd.org
- $OpenBSD: porting.html,v 1.9 1998/08/12 22:13:02 marc Exp $ +
$OpenBSD: porting.html,v 1.10 1998/08/13 23:11:18 espie Exp $