Bug 470815

Summary: setutent_file returns with permission failure
Product: [Fedora] Fedora Reporter: Steve Grubb <sgrubb>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: drepper, jakub, lmacken
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-16 22:04:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 475332    
Attachments:
Description Flags
patch attempting to fix problem none

Description Steve Grubb 2008-11-10 13:36:48 UTC
Created attachment 323068 [details]
patch attempting to fix problem

Description of problem:
The setutent_file function call attempts to open /var/run/utmp with write permissions even if the user has no hope of being successful. utmp is a security sensitive file and people typically place audit watches on that file. They attempt to look for permission denied failures since that would indicate someone potentially trying to subvert the user activity logs. 

The zabbix program for example calls "who" once a minute to look for changes in logins. "Who" is run from its login account. Therefore, we get about 1400 of these failures a day. We would like to quieten this down by checking first if the user can open the file with write permissions and then make the right decision.

I'm attaching a patch that should make this easier on IDS systems (since there is less unintended permission failures) and still preserve the library's intended behavior.

Comment 1 Ulrich Drepper 2008-11-11 05:16:51 UTC
In principle is not a problem.  But it seems isolated.  Aren't there any other cases like this?

As for the patch itself:

- access isn't really the right function.  euidaccess is.

- euidaccess has no support for ACLs.  ACL-based permission device violations
  are also audited, right?

- the formatting is wrong

Comment 2 Steve Grubb 2008-11-12 12:44:09 UTC
Dan Walsh and I looked the selinux policy. He says there are about 20-30 applications that have permissions around the utmp file. They seem to be anything that wants to do a "wall" or broadcast message or determine ttys of users that may be logged in. Its just that "who" is the one that caught our eye and is readily reproducible.

As for access vs euidaccess, I was not aware of the latter function. I know that some apps are setgid utmp and that access takes that into account when calculating permission. I know older systems used setuid apps to access utmp. So, I was thinking that access was more flexible since real uid & gid are taken into account. But I don't think we use ACLs to guard utmp. 

The audit system (and by extention the IDS) can see ACL originating permission violations. Thanks.

Comment 3 Ulrich Drepper 2008-11-12 13:16:45 UTC
(In reply to comment #2)
> Dan Walsh and I looked the selinux policy. He says there are about 20-30
> applications that have permissions around the utmp file. They seem to be
> anything that wants to do a "wall" or broadcast message or determine ttys of
> users that may be logged in. Its just that "who" is the one that caught our eye
> and is readily reproducible.

That's not what I meant with isolated.  glibc tries opens other files without the prospect of succeeding.  The utmp stuff is just one case.


> As for access vs euidaccess, I was not aware of the latter function. I know
> that some apps are setgid utmp and that access takes that into account when
> calculating permission. I know older systems used setuid apps to access utmp.
> So, I was thinking that access was more flexible since real uid & gid are taken
> into account.

access(2) is a horrible interface and almost always the wrong one to use.  Very few exceptions.


> But I don't think we use ACLs to guard utmp. 

That doesn't matter.  The question is whether someone might do, for utmp or other files which need to be protected.  Ideally I'd hope the kernel takes case of this...



> The audit system (and by extention the IDS) can see ACL originating permission
> violations.

Which means that ACLs have to handled in euidaccess or in the kernel's sys_access.


I'm not in the least interested in changing the code for the sole purpose of quieting down the audit system.  This must be a generic solution and it must be complete.

Comment 4 Bug Zapper 2008-11-26 05:07:49 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Ulrich Drepper 2008-12-02 01:44:13 UTC
I've checked in upstream a patch to avoid the open-for-write in most cases.  In those cases where it still happens it is needed.

Comment 9 Jakub Jelinek 2008-12-08 14:53:00 UTC
Please try http://kojipkgs.fedoraproject.org/packages/glibc/2.9/3/

Comment 10 Steve Grubb 2008-12-14 13:26:09 UTC
Just tested the -3 package and yes it does solve the problem. Thanks!

Comment 11 Ulrich Drepper 2009-03-16 22:04:28 UTC
I'm closing this bug because Fedora is changed.  If you need it for RHEL, open a new bug.