On Mon, 2006-12-11 at 09:16 -0500, Stephen Smalley wrote: > On Fri, 2006-12-08 at 18:49 -0600, Michael C Thompson wrote: > > Stephen Smalley wrote: > > > On Thu, 2006-12-07 at 18:15 -0500, Linda Knippers wrote: > > >> I was having intermittent problems with the 'more' command and finally > > >> had a chance to identify the problem. > > >> > > >> The symptom is that 'more' will abort after one screen full, getting > > >> an EBADF when it tries to read the user input. It doesn't matter if > > >> the system is in permissive mode. The issue is that 'more' is reading > > >> stderr. That's not a problem until one runs 'newrole', which is > > >> paranoid about stdout and stderr, reopening them as WRONLY. > > >> > > >> I filed a bugzilla on the problem. > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218880 > > >> > > >> Do we change 'more'? I wonder what else will stop working with the > > >> current 'newrole' behavior. > > > > > > I think we revert newrole to its prior behavior (it used to open all > > > three descriptors rw, but that was "cleaned up"). > > > > So I'm not sure why more would be reading stderr, that doesn't make > > sense at all to me. Assuming this is unreasonable, we shouldn't be > > changing newrole, but fixing more. > > I created a trivial test program that tried to read and write each of > descriptors 0-2, and ran it from the shell, and it encountered no > errors. So applications may have come to depend on such behavior, and > we don't want newrole to break compatibility unless there is some > security rationale for doing so. Only scenario there is if we would > ever want the newrole'd shell to be able to inherit stdin (i.e. read) > but not {stdout, stderr} (i.e. write) or vice versa. They all refer to > the same object here (the tty, re-opened by newrole itself). > > Remember as well that we not only have to consider applications included > in the distro itself but also third party applications, both open source > and otherwise. > > > Also, at what point did this "clean up" take place? Because (admittedly > > I almost never use more), I don't ever recall this being an issue. > > I think that the change from O_RDWR on all three descriptors to O_RDONLY > for stdin and O_WRONLY for stdout and stderr happened during a cleanup > by Steve Grubb almost a year ago in preparation for his patches to add > audit support to newrole (which was the first change to require newrole > to be suid). At the time, I believe I mentioned compatibility as a > possible concern, but couldn't remember a specific example of breakage.
Looks like this did come up last May on fedora-selinux-list, but was never fixed: http://marc.theaimsgroup.com/?l=fedora-selinux-list&m=114866384906455&w=2 -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
