March 8th, 2012

Excuse me son, but your code is leaking !!!

I have written over the years about leaked file descriptors, and what a pain they have been to SELinux.

C on Unix many many years ago was designed to leak by default.  A file descriptor is leaked if you open a file descriptor or socket and then do a fork/exec.  The new process will automatically get access to the file descriptor unless SELinux blocks it. 

When SELinux blocks the leaked file descriptor you usually end up with a strange looking AVC about the new domain trying to read or write a random file or a socket owned by the parent or even worse an ancestor.

Talking with Uli Drepper the other day about leaked file descriptors.  He reminded me that the gcc/glibc teams had added a flags to open,fopen, socket, accept4 to change the default.

man open
By  default,  the  new  file descriptor is set to remain open across an execve(2) (i.e., the  FD_CLOEXEC  file  descriptor  flag  described  in fcntl(2)  is  initially  disabled; the O_CLOEXEC flag, described below, can be used to change this default).
O_CLOEXEC (Since Linux 2.6.23)          Enable the close-on-exec  flag  for  the  new  file  descriptor. Specifying  this  flag  permits  a  program  to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC  flag.   Additionally,  use  of  this flag is essential in some multithreaded programs since using a separate fcntl(2)  F_SETFD  operation  to set  the  FD_CLOEXEC  flag does not suffice to avoid race conditions where one thread opens a file descriptor at the same  time as another thread does a fork(2) plus execve(2).

Sadly this can not be made the default, but as a good programing practice all open/socket,accept and fopen calls should use this flag in order to close the file descriptor by default.

open(path, O_CLOEXEC | flags)
accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, SOCK_CLOEXEC | flags);
fopen(path, "re")

If you can not open a file descriptor with one of these commands then you can execute

fctnl(fd, F_SETFD, FD_CLOEXEC)

He gcc developers or code analysys tools, you probably should catch when leaks happen, especially if they are not STDIN, STDOUT, STDERR.

Just be neat and stop leaking all over the place.

Fedora 17 New Security Feature part VI - man pages for SELinux user/role domains

Ok, maybe this should be Security Feature IV.5 but Roman numerals do not support decimal points.  :^)

After I wrote the tool to generate service domains man pages, Miroslav Grepl thought it would be a good idea to generate similar policy for user domains and roles.

We hacked up a new script called segenuserman, which generates 13 new SELinux user and Role man pages.

auditadm_selinux.8  git_shell_selinux.8  logadm_selinux.8 secadm_selinux.8    sysadm_selinux.8 user_selinux.8    xguest_selinux.8 dbadm_selinux.8 guest_selinux.8  nx_server_selinux.8  staff_selinux.8 unconfined_selinux.8  webadm_selinux.8

Note segenuserman also requires

Here is the staff_selinux.8 for an SELinux user, and webadm_selinux.8 for an SELinux role.

I have also updated the SELinux service domain man pages to include booleans,process types, file context paths, better descriptions, network ports.

Here is an update zebra_selinux.8