Bug 695815 - /var/log/prelink/ should be mode 0700, not 0755
Summary: /var/log/prelink/ should be mode 0700, not 0755
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: prelink
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-12 18:34 UTC by Vincent Danen
Modified: 2011-04-20 17:42 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-20 17:42:29 UTC
Type: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.