Bug 695815

Summary: /var/log/prelink/ should be mode 0700, not 0755
Product: [Fedora] Fedora Reporter: Vincent Danen <vdanen>
Component: prelinkAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: jakub
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-20 17:42:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Vincent Danen 2011-04-12 18:34:43 UTC 
The /var/log/prelink/ directory is mode 0755, and the /var/log/prelink/prelink.log file is mode 0644.  Because memory addresses are recorded in /var/log/prelink/prelink.log, these permissions are a bit excessive.

I don't believe any non-root userspace tools require access to this file, so it would be better to have /var/log/prelink/ as mode 0700 or 0750 to prevent non-root users from looking at the log file.

I don't believe this is a security flaw that needs to be fixed in existing releases; but we should fix it in Fedora 15 so that the file is protected in future releases.
Comment 1 Jakub Jelinek 2011-04-19 09:47:38 UTC 
Actually, think about it some more, it doesn't make much sense, since /etc/prelink.cache is world readable and anyone can prelink -pv
to get at the addresses too.  And restricting read access to /etc/prelink.cache would make it impossible for users to prelink their own binaries.
Comment 2 Vincent Danen 2011-04-19 17:30:02 UTC 
Ahh, good point.  Yeah, if we did restrict /etc/prelink.cache and the log file, we would have to make prelink executable only by root and, as you say, then a user could not prelink their own binaries.  The only real way that I could see to fully secure all of this is to have a group 'prelink', similar to the 'fuse' group for fusermount.

Is the extra complexity worth it though?  I don't know what an attacker could do with the memory addresses; I suppose it could make their job a bit easier (assuming for some pre-existing vulnerability that they can take advantage of).  I can't think off-hand of how it would be a problem on its own, without having something vulnerable to attack first.

Am I missing anything?  If not, then we could probably close this as WONTFIX or even NOTABUG.

Thanks for looking into it, Jakub.  The Debian bug report implied this was a fairly serious information leak, but perhaps they didn't look at the whole angle (or don't care about users being able to prelink their own stuff).
Comment 3 Jakub Jelinek 2011-04-19 17:44:01 UTC 
Do we actually have any libraries that aren't other readable though?
We have a few such binaries, but the base address of binaries isn't stored there, just info whether it is prelinked or not and PIEs aren't prelinked.
On my F14 x86_64 box I didn't find any such libraries in prelink -pv output.
If a library is other readable, then readelf -Wl or readelf -Wa will reveal many more details, including the base address.
Comment 4 Vincent Danen 2011-04-20 17:42:29 UTC 
Oh wow.  Yeah, readelf -Wa reveals a lot.  The output that provides really puts what prelink provides to shame.

I don't think we have any libs that are user/group-restricted.  Programs, yes, but not libraries (at least none that I can see).

I think it is safe to close this as NOTABUG.