|Main Archive Page > Month Archives > selinux archives|
On Tue, Jun 16, 2009 at 10:01 PM, Stephen Smalley<firstname.lastname@example.org> 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
> 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 email@example.com with the words "unsubscribe selinux" without quotes as the message.