#286 permission on files and directories
Closed: Fixed None Opened 9 years ago by sundaram.

As a followup to comment 2 at https://fedorahosted.org/fpc/ticket/283, I would request fpc to add the following generic guideline adopted from Debian policy. Thanks for your consideration.

Files should be owned by root:root, and made writable only by the owner and universally readable (and executable, if appropriate), that is mode 644 or 755.

Directories should be mode 755 or (for group-writability) mode 2775. The ownership of the directory should be consistent with its mode: if a directory is mode 2775, it should be owned by the group that needs write access to it

Setuid and setgid executables should be mode 4755 or 2755 respectively, and owned by the appropriate user or group. They should not be made unreadable (modes like 4711 or 2711 or even 4111); doing so achieves no extra security, because anyone can find the binary in the freely available Fedora package and just causes inconvenience. For the same reason you should not restrict read or execute permissions on non-set-id executables.

Some setuid programs need to be restricted to particular sets of users, using file permissions. In this case they should be owned by the uid to which they are set-id, and by the group which should be allowed to execute them. They should have mode 4754; again there is no point in making them unreadable to those users who must not be allowed to execute them.

abadger1999's simplified draft (​http://www.fpaste.org/12580/13687220/) approved (+1:8, 0:0, -1:0)

Toshio will follow up with RH Security about concerns with the second part.

First part added to the guidelines. Announcement writeup:

The file permissions guidelines have been added to to give slightly more specific guidance about what correct file permissions are.


The short answer from bressers and Dhiru Kholia is that it is fine to recommend that executables are readable. The longer answer is a bit more complex:

  • In theory all setuid binaries should be compiled with PIE. PIE does address randomization every time a program runs so there's no hole opened up by allowing users to read the on-disk program file.
  • We do have some setuid binaries that are not currently compiled with PIE. Dhiru says he's opened about 40 bugs to ensure that all setuid executables are compiled with PIE.
  • Prelink works by randomizing the address of libraries when prelink is run. It does not randomize every time the program is run.
  • Prelinked binaries will lose some protection if they are readable, however, prelinked binaries are not very well protected against local attack anyways. A local attacker could write an exploit that tries lots of addresses until they find the right one. Depending on the type of exploit, it could be possible to try thousands or millions of addresses per second.

So bressers' advice is that thinking that marking setuid applications read-only is a false sense of security that doesn't help for any of our use cases. And we really need to make sure that setuid binaries are compiled with PIE :-)

Is there a tracker bug for this? If so, posting it to devel list could help provenpackagers fix the PIE and we could add the appropriate guidelines not to think that marking anything read-only helps with security.

And of course those bugs shouldn't have been opened without some discussion about it, and the opened bugs don't actually tell the packagers what to do. I'm not sure why the PIE thing is lumped in with this ticket, but I'd hate to think that somehow we gave someone the idea that filing all of those tickets was a good idea.

PIE is connected to this ticket as per the statement from the security team. can the guidelines be updated? thanks

Does anyone know the current status on this? I requested that fpc cover this in https://lists.fedoraproject.org/pipermail/devel/2013-May/183494.html and not sure anyone followed up after that.

I think this issue has been dealt with as part of the resolution of https://fedorahosted.org/fpc/ticket/467

Metadata Update from @toshio:
- Issue assigned to spot

5 years ago

Login to comment on this ticket.