dnebdal at gmail.com
Mon Oct 7 13:38:00 UTC 2013
On Mon, Oct 7, 2013 at 2:52 PM, Anton Shterenlikht <mexas at bris.ac.uk> wrote:
> >From bsam at passap.ru Mon Oct 7 13:36:53 2013
>>07.10.2013 13:23, Anton Shterenlikht пишет:
>>> What about "make fetch"? It puts files by default under
>>> ports/distfiles, which, by default, is 755:
>>> What about "make extract"? Same problem:
>>I use svn repo owned by a user for ages. When a root rights are needed,
>>the ports infrastructure asks for the password.
> I've read a few books on unix security.
> The typical advice is to assume the user
> passwords are compromised.
> If I build and install from a ports tree
> owned by a user, I increase the chances of
> comromising the system, if an attacker
> changes some files in the ports tree,
> i.e. the URL in the Makefile and the checksum
> in distinfo. I'll then have to add this worry
> to my already long list.
If that happens to an account used by an admin, don't you have larger worries?
Let's say :
* You have an account with no special privileges, that you typically
log in with.
* That account has a ports tree
* You typically install ports by compiling them as this user, then
installing them with root privileges.
If you use sudo, and you haven't used targetpw or something to make it
ask for a different password, and you haven't set any strong limits on
it, anyone that got your password would also be able to use sudo to do
whatever they wanted more directly. So let's assume you're not doing
An attacker with your password could meddle with your .profile or
.cshrc or whatever, and replace your shell with a lookalike that
logged all input. From there, they could get hold of whatever commands
and passwords you use to install software, and reuse that to install
whatever they want directly. If what you use is sudo, somehow
restricted to only run make install, and only within that ports tree
... again, what would keep an attacker from just modifying any random
port on the fly, installing it there and then, and then reverting the
changes to reduce the risk of detection?
It just seems like leaving a timebomb in the form of a modified ports
directory would be a fairly inefficient thing to do if they'd already
gotten that far., and it would run the risk of being overwritten
and/or detected next time you updated your ports tree. Of course, if
you set the ports tree a+w (or, heaven forbid, 0777), you'd be asking
for trouble ... but that's not new.
Then again, I might have overlooked something. :)
More information about the freebsd-ports