On Tue, Jun 16, 2009 at 10:01 PM, Stephen Smalley<sds@xxxxxxxxxxxxx> wrote: > > In this particular case it doesn't appear to be a problem, but often > programs unwittingly leak file descriptors when they exec a child > program. Thus, this permission check has often been helpful in catching > such unintentional leaks, which can ultimately prove to be > security-relevant (leaking access to some resource that shouldn't be > accessible to the new program). > > There are two checks applied: > - the fd use check, which controls whether a process can use a > descriptor originally opened by a process in a different security > context, and > - the file read/write/append checks, which control whether the process > can access the file in accordance with the open file flags. > > If either set of checks fails, then the descriptor is closed and > replaced with a reference to the null device (to avoid application > misbehavior). > > Naturally, if the passing of the descriptor is intentional and valid, > you can allow it in policy. So are you saying that this /dev/null access by syslog-ng is actually because some other access actually failed? I don't see how this could be either: # semanage fcontext -l|grep logrotate /etc/cron\.(daily|weekly)/sysklogd regular file system_u:object_r:logrotate_exec_t:s0 /var/lib/logrotate(/.*)? all files system_u:object_r:logrotate_var_lib_t:s0 /usr/sbin/logrotate regular file system_u:object_r:logrotate_exec_t:s0 Note that the odd sysklogd entry doesn't exist in either of those two directories. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
