Big Security Problems With makepkg/pacman

romankreisel · 2003-08-07 20:27:28

Hi all!

I just found a big security-problem:

i built some packages with my normal user (not as UID 0) because every security-guide tells you never to compile code as root (in fact: don't do anything as root, what you could do as user). Maybe some of you still remember of the backdoor in the buildscripts of irssi: one more reason not to build packages as root!

It worked all fine, i compiled it, packaged it, became root and installed it using pacman. Now, one day later, i just found out, that the files which where installed to /usr/bin still belong to THE USER, not to root! they weren't chmodded neither during "makepkg" nor during "pacman -A".

I see three possibilities to fix this bug:

1. (the easiest): let pacman chown root:root all files during "pacman -A". But remember this could break some packages which install files which shall not belong to root. They would have to chmod those files in their install-scripts in the future

2. (IMHO the best): Use fakeroot as debian does! It works fine and i really see no reason why not to use it!

3. (If you're lazy ;]) move makepkg to /usr/sbin, so only UID has makepkg in it's $PATH... but remember that you force all arch-developers and users to build their packages as root, if you do this. They will be exposed to backdoors which might be hidden in build-scripts (./configure, Makefile, etc.)

Regards
Roman

neri · 2003-08-07 23:32:51

romankreisel wrote:

Hi all!
I just found a big security-problem:
i built some packages with my normal user (not as UID 0) because every security-guide tells you never to compile code as root ....
It worked all fine, i compiled it, packaged it ...

1. Usually, packages should be built from /usr/abs or /usr/abs/local which
is owned by root and has 755. So it is, as a preference, impossible to build
packages there as oridinary user.

2. The next point is, what exactly could happen, if these files are owned by
THE USER.

3. Finally, and I think that is the most important thing - if people don't play
by the rules - as mentioned in point one, it could damage the computer.
Furthermore, if some people have the criminal energy to write "harmful
pkg's" they have an even more powerful toy: pacman -A must be called
as root. Now think about an install-script with

 post_install() {
  rm -rf /lib
}

I think there is no guarantee, that all pkg's are harmless. AFAIK there is
a feature planned for the next release of pacman to implement a MD5
check for the packages from the official servers. Who gets packages from
elsewhere has to know what he/she is doing.

bye neri

romankreisel · 2003-08-08 00:19:01

neri wrote:

1. Usually, packages should be built from /usr/abs or /usr/abs/local which
is owned by root and has 755. So it is, as a preference, impossible to build
packages there as oridinary user.

So you really want to compile everything as root? Don't you care even a little bit about security? You should do as much as possible as normal user without additional rights, and compiling software doesn't need root-rights, so why should packaging do it?

neri wrote:

2. The next point is, what exactly could happen, if these files are owned by
THE USER.

I really have to tell you what might happen, if a user could replace e.g. /bin/bash by his own binary? The Answer is: the next time root logs in (and starts bash) the machine might be owned by the user who this file belongs to!

neri wrote:

3. Finally, and I think that is the most important thing - if people don't play
by the rules - as mentioned in point one, it could damage the computer.

So, it is archlinux who doesn't "play by the rules" with putting makepkg into /usr/bin instead of /usr/sbin, if it should really only be run by root (which i still consider as absolutely stupid!)

neri wrote:

Furthermore, if some people have the criminal energy to write "harmful
pkg's" they have an even more powerful toy: pacman -A must be called
as root. Now think about an install-script with
 post_install() {
  rm -rf /lib
}

I'm not talking about trustful sourcecode and/or packages, but the basic rules of security! Never use root when you ABSOLUTELY don't have to!

neri wrote:

I think there is no guarantee, that all pkg's are harmless. AFAIK there is
a feature planned for the next release of pacman to implement a MD5
check for the packages from the official servers. Who gets packages from
elsewhere has to know what he/she is doing.

As mentioned above, this hasn't anything to do with my post.

I'm going to tell you the things which annoy me again:

1. You must be root to build arch-packages, this is stupid, insecure and absolutely unnecessary!

2. By putting the current makepkg in /usr/bin, you mislead people to build packages which might screw up their systems!

I hope, that you resolve these problems as soon as possible (I'll try to build a fakeroot-package this weekend, which might help you with this task), because security is for me (and for sure also for many other Linux-users) an absolut K.O.-argument.

sarah31 · 2003-08-08 05:59:48

there is a unofficial and undistributed version of makepkg around that uses fakeroot which i had been using for awhile. with it all ownership belongs to the user who compoiles the package. so fakeroot does not cut the mustard for building packages.

there were a fair number of packages that simply cannot be compiled or installed into a package with fakeroot. makepkg2 was great for testing builds but is wholly unpractical for building packages.

Xentac · 2003-08-08 15:54:06

1. Pacman/makepkg shouldn't assume that all the files' permissions are supposed to be root:root. That's just silly.

2. Fakeroot was tried once. It led to many problems, partially because it wasn't used correctly. The current build system doesn't really have room for fakeroot, unless you created fakeroot enabled PKGBUILDs...

3. Ever checked your PATH? All users have /usr/sbin in their PATH anyway...

The reason you can build packages as users with makepkg is to allow testing of packages before you actually build a proper package. That way you can check to see if stupid build systems are trying to put files where they're not supposed to.

At least... that's the way I use it...

romankreisel · 2003-08-08 17:43:54

Xentac wrote:

1. Pacman/makepkg shouldn't assume that all the files' permissions are supposed to be root:root. That's just silly.
2. Fakeroot was tried once. It led to many problems, partially because it wasn't used correctly. The current build system doesn't really have room for fakeroot, unless you created fakeroot enabled PKGBUILDs...
3. Ever checked your PATH? All users have /usr/sbin in their PATH anyway...
The reason you can build packages as users with makepkg is to allow testing of packages before you actually build a proper package. That way you can check to see if stupid build systems are trying to put files where they're not supposed to.
At least... that's the way I use it...

Well... since nobody here seems to care for stability and norms, i seem to be at the wrong place...
BTW, i just read the FHS and it tells that /usr/sbin and /sbin are the place where binaries which are only meant to be run as root should be placed... so why do you put it into $PATH for all users?

Well... guess this was the last message i wrote from my archlinux-installation

sarah31 · 2003-08-08 18:00:24

romankreisel wrote:

Well... since nobody here seems to care for stability and norms, i seem to be at the wrong place...
BTW, i just read the FHS and it tells that /usr/sbin and /sbin are the place where binaries which are only meant to be run as root should be placed... so why do you put it into $PATH for all users?

umm.. i care about stability and arch is stable i have used it for a year. without issue.

usr/sbin and sbin are indeed in the path of users (like i remember it to have been in debian and gentoo) but still the apps in there require root permissions. because a PATH exists for a user does not automatically give user permissions to run the apps in it. take cdrecord for example just try running it as user without changing permissions. and so forth.

Well... guess this was the last message i wrote from my archlinux-installation

almost every distro i have used required at least some root permissions to build, install, etc packages and source. in fact some source defeinitely requires root to just build no sudo, no fakeroot just root. debian for example required root to build packages, as i recall.

since you seem to be so knowledgable and concerned with the build system arch has then feel free to contact the head developer and tell him how to change the code to suit your needs. if you have coding skills fix the code and submit a patch. any useful suggestions and patches are usually welcomed.

sarah31 · 2003-08-09 01:01:09

after some thought time and a ery good irc discussion with roman i would publicly like to apologize to him and the readers of this thread.

further, on discussing this issue with roman some more i have to say i agree that the current makepkg presents a potential serious risk as it currently stands.

i will discuss these issues with judd and present him with the fixes that roman was kind enough to furnish me with.

Mork II · 2003-08-09 12:49:20

First of all: There is no need to get upset.

Second (from the FHS):

We recommend that users have read and execute permission for everything in /sbin except, perhaps, certain setuid and setgid programs. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. There is no inherent security advantage in making /sbin off-limits for users.

As previosly pointed out users need to build packages, hence makepkg in /usr/bin.

The problem is makepkg requiring root (since it doesn't run makeinstall there is no need)? If I understand correctly the reason for makepkg beeing run as root is ownership on /usr/abs? Isn't it enough to change this then?

romankreisel · 2003-08-12 22:56:18

Mork II wrote:

First of all: There is no need to get upset.
Second (from the FHS):
We recommend that users have read and execute permission for everything in /sbin except, perhaps, certain setuid and setgid programs. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. There is no inherent security advantage in making /sbin off-limits for users.
As previosly pointed out users need to build packages, hence makepkg in /usr/bin.
The problem is makepkg requiring root (since it doesn't run makeinstall there is no need)? If I understand correctly the reason for makepkg beeing run as root is ownership on /usr/abs? Isn't it enough to change this then?

First of all, about the FHS: The FHS tells you, that Users > UID 0 should have read+execute permissions to files in (/usr)/sbin, but it doesn't tell to put those paths in their $PATH-variable

second: as long as makepkg builds packages with files belonging to $USER instead of root, they mustn't build packages! Else they would risk their system, if their useraccount is hacked! Therefore, makepkg should be placed in /usr/sbin until this issue is fixed

third: users can still compile packages outside of /usr/abs

and, last but not least: wouldn't be /var/abs a better place for the abs, anyway? the files in there are changed frequently and files in /usr aren't meant to be changed frequently...

neri · 2003-08-13 07:51:53

Hi roman,

romankreisel wrote:

third: users can still compile packages outside of /usr/abs
and, last but not least: wouldn't be /var/abs a better place for the abs, anyway? the files in there are changed frequently and files in /usr aren't meant to be changed frequently...

/usr/abs is not fixed, since you can set $ABSROOT in /etc/makepkg.conf.
This is currently not working perfektly, because the path for downloading
the PKGBUILDs in "abs" is still hard-coded, which is matter to be changed.

Do you consider this an a security issue (I would like that feature), or do
you just wann achange the preference for the abs-tree?

bye neri

apeiro · 2003-08-13 17:52:56

romankreisel: Sarah has emailed me your fakeroot-ified makepkg, and I'll take a look at it when I find some spare minutes.

I agree with your /var/abs point, and pacman 2.6's abs script will pay attention to makepkg.conf's ABSROOT, which will default to /var/abs.

/sbin and /usr/sbin will stay in the default PATH, as there are too many useful programs there that myself (and presumably other linux users) find handy to access with non-root access. And removing the sbins from PATH is hardly much of a deterrent, just more of an annoyance for those of us that actually use the sbins regularly.

Mork II · 2003-08-13 18:31:58

romankreisel wrote:

First of all, about the FHS: The FHS tells you, that Users > UID 0 should have read+execute permissions to files in (/usr)/sbin, but it doesn't tell to put those paths in their $PATH-variable

Let me try again: The reason for not using the path variable is the possibility that user-account has been comprimised and $PATH hacked to redirected you to something naughty? A prime example would be rerouting su to a script that captures keyboard input while visibly only running su, Therby giving the attacker root. Point taken. The full path to su is /usr/bin/su. There is a risk in using $PATH wether it points to */bin or */sbin, as it is in having su installed. Yet both solutions are convenient and therefore often used.

romankreisel wrote:

second: as long as makepkg builds packages with files belonging to $USER instead of root, they mustn't build packages! Else they would risk their system, if their useraccount is hacked! Therefore, makepkg should be placed in /usr/sbin until this issue is fixed

Ok, I think I get your point.
- If you ran makepkg as root you risk getting your system comprimised if someone has tampered with the code (as with irssi). So building as root is bad.
- However building as user is bad since you risk getting rooted if a user account gets compromised. Wich files are owned by user after a makpkg? Binarys, conf-files? Binarys or scripts are more dangerous, while conf-files only can be used to exploit bugs.

How should this be solved? Proposed possibilites are:
- All files are belong to root. Problem: Breaks packages.
- Fakeroot. Problem: Breaks packages. Might work if PKGBUILDS for fakerootbuilding were created?
- Moving makepkg to /usr/sbin, removing $PATH to /usr/sbin to make it hard/impossible for users to makepkg. Problem: Makepkg is run as root. Introduces the problem of tampered code being run.

So there is no easy answer. Wich is the best solution (if we forget fakeroot for a while)? I see nothing good in making makepkg run as root.

romankreisel wrote:

third: users can still compile packages outside of /usr/abs

Yes, soon at least. Do you consider this a problem?

Forgive me if I ignore messages written in the last three-four hours or so. I got interrupted by a phonecall.

romankreisel · 2003-08-16 08:43:47

Mork II wrote:

Let me try again: The reason for not using the path variable is the possibility that user-account has been comprimised and $PATH hacked to redirected you to something naughty? A prime example would be rerouting su to a script that captures keyboard input while visibly only running su, Therby giving the attacker root. Point taken. The full path to su is /usr/bin/su. There is a risk in using $PATH wether it points to */bin or */sbin, as it is in having su installed. Yet both solutions are convenient and therefore often used.

I guess, i got missunderstood again. The $PATH-Problem is NOT security-related. But when i said, that you should move makepkg to /usr/sbin if ordinary users shouldn't use it, someone replied that /usr/sbin is also in the $PATH of all users. Then I replied, that this shouldn't be... I guess we shouldn't discuss this any longer

Mork II wrote:

Ok, I think I get your point.
- If you ran makepkg as root you risk getting your system comprimised if someone has tampered with the code (as with irssi). So building as root is bad.
- However building as user is bad since you risk getting rooted if a user account gets compromised. Wich files are owned by user after a makpkg? Binarys, conf-files? Binarys or scripts are more dangerous, while conf-files only can be used to exploit bugs.

ALL files in th package are owned by the user who built it!

Mork II wrote:

How should this be solved? Proposed possibilites are:
- All files are belong to root. Problem: Breaks packages.
- Fakeroot. Problem: Breaks packages. Might work if PKGBUILDS for fakerootbuilding were created?
- Moving makepkg to /usr/sbin, removing $PATH to /usr/sbin to make it hard/impossible for users to makepkg. Problem: Makepkg is run as root. Introduces the problem of tampered code being run.

Fakeroot is the solution. I've seen the implementation someone tried in makepkg... it was just absolute wrong used! I already sent a patch to Sarah which integrates it absolutely correctly... and it definetly doesn't break packages, debian uses fakeroot for all of it's packages iirc

Mork II wrote:

So there is no easy answer. Wich is the best solution (if we forget fakeroot for a while)? I see nothing good in making makepkg run as root.

Why should we forget about fakeroot?
Well.... you could still build a chroot for building packages, but i guess this would increase the build-time about a few minutes for every package.

Mork II wrote:

romankreisel wrote:

third: users can still compile packages outside of /usr/abs
Yes, soon at least. Do you consider this a problem?

This was also, because someone said that only root can/should run makepkg, since only root has write-access to /usr/abs

Regards
Roman

Mork II · 2003-08-16 12:15:23

Ok, thanks. I think I finally understood. Hope the fakerootenabled makepkg works. Thank you for your persistance ;-)

Arch Linux

#1 2003-08-07 20:27:28

Big Security Problems With makepkg/pacman

#2 2003-08-07 23:32:51

Re: Big Security Problems With makepkg/pacman

#3 2003-08-08 00:19:01

Re: Big Security Problems With makepkg/pacman

#4 2003-08-08 05:59:48

Re: Big Security Problems With makepkg/pacman

#5 2003-08-08 15:54:06

Re: Big Security Problems With makepkg/pacman

#6 2003-08-08 17:43:54

Re: Big Security Problems With makepkg/pacman

#7 2003-08-08 18:00:24

Re: Big Security Problems With makepkg/pacman

#8 2003-08-09 01:01:09

Re: Big Security Problems With makepkg/pacman

#9 2003-08-09 12:49:20

Re: Big Security Problems With makepkg/pacman

#10 2003-08-12 22:56:18

Re: Big Security Problems With makepkg/pacman

#11 2003-08-13 07:51:53

Re: Big Security Problems With makepkg/pacman

#12 2003-08-13 17:52:56

Re: Big Security Problems With makepkg/pacman

#13 2003-08-13 18:31:58

Re: Big Security Problems With makepkg/pacman

#14 2003-08-16 08:43:47

Re: Big Security Problems With makepkg/pacman

#15 2003-08-16 12:15:23

Re: Big Security Problems With makepkg/pacman

Board footer