Bug 624043

This leak was in code for a long time, but the latest changes, probably in selinux-policy, reveal it. Even if this couldn't be reproduced on RHEL, it should be fixed.

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

I do not understand the report that generated a lot of SELinux. Does the error may be an attack?, Error occurred at night, the computer stays on downloading files from a torrent with Transmission program.

Sorry, my English is not very good. Thank you.

No it is most likely not an attack but a bug in cronie.

I think cronnie is opening /root and not setting the the file descriptor

fcntl(fd, F_SETFD, FD_CLOEXEC)

This means the file descriptor is leaked to all apps that cronnie starts.  Apps that are confined report this as an AVC error and close the file descriptor.

Other apps can list the contents of the /root directory.

I had the same problem with Fedora 13 on a x86 system.

I had the same problem with Fedora 13 on a x86_64 system.

I'm having the same problem with F14 developmental branch.

Gene

 I just got this error on Fedora 13, x86_64 system

(In reply to comment #8)
(In reply to comment #10)
Confirmed here, too.

Got this problem on Fedora 13, x86_64 system, using Oracle VM VirtualBox.

For me it is the same on Fedora x86_64 report today

(In reply to comment #0)
> SELinux is preventing /bin/bash access to a leaked /root file descriptor.
> 
> Detailed Description:
> 
> [prelink has a permissive type (prelink_cron_system_t). This access was not
> denied.]

What is a "leaked ... file descriptor"?

In C code, when you open a file or socket you get a file descriptor, that you can use to read and write.

By default when you fork another process that process inherits access to the file descriptor.  If you execute a program from that process, the new process inherits (leaks) the file descriptor.

The reason this was done in the beginning was to allow processes to use STDIN, STDOUT, STDERR. (0,1,2) But it can lead to problems.

Most file descriptors should not be allowed to be inherited (leaked) to other programs.

If you look at the "man open" you will see the following

"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  Linux-specific 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.   Addi‐
              tionally,  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 condi‐
              tions where one thread opens a file descriptor at the same  time
              as another thread does a fork(2) plus execve(2).

"

I encountered this issue several times on my Fedora 13 on a x86 system.

I encountered this sevreal times since Aug.12 on my x86 Fedora13 box, while just editing a file form my git local repo in emacs.

This bug is reported against RHEL6 but when I selected to file the SELinux alert via report I was on F13 system.

(In addition to comment #17)

I omitted to say my box runs 32bits and uname -r is:
2.6.33.6-147.2.4.fc13.i686.PAE

(In addition to comment #17)

I omitted to say my box runs 32bits and uname -r is:
2.6.33.6-147.2.4.fc13.i686.PAE

This is RHEL bug, please use Bug #623908 for Fedora reports. And moreover the bug is already solved in the testing update cronie package. Please install it, restart crond and report only when the problem reappears after that.

(In reply to comment #21)
> This is RHEL bug, please use Bug #623908 for Fedora reports. And moreover the
> bug is already solved in the testing update cronie package. Please install it,
> restart crond and report only when the problem reappears after that.

Sorry if this is not the right place, but that's where Selunix invited me when I reported (link provided in the popped up box).

That was caused by the copied setroubleshoot hash when the bug was cloned. Hopefully for new reports it should find the original Fedora bug.

*** Bug 624223 has been marked as a duplicate of this bug. ***

*** Bug 624284 has been marked as a duplicate of this bug. ***

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment #36 => Verified=SanityOnly.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0788.html