Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
On Tuesday, 2002-01-22 at 01:11:18 +0100, Christian Jaeger wrote: (BTW a somewhat similar problem (but not debian specific) exists with the perl CPAN module build process: -MCPAN is designed to work as root. It downloads the tarball, extracts it (with the user/group that the author packed them) as root, thus you are left with files belonging to random system users. -MCPAN doesn't take any precautions to protect the .cpan/build/ folder, thus with a bit luck some user on the system can modify the unpacked files before they are built/installed by root.) You do not need to run the CPAN build process as root. You *mey* need the root account to install the packages (which, I admit, is conveniently done from the CPAM.pm module). Now, if your site specific CPAN directories do not belong to root, you don't need even that. However, if then other perl library directories *are* owned by root, you have trouble with new versions of Perl Core modules - perl will always pick the old ones in the system library directories because of the standard @INC. Should those directories be owned by a perl owner use in Debian to prevent possible exploits from Perl modules? It's easy to catch somebody unawares from a Makefile.PL. Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
On Tue, Jan 22, 2002 at 01:59:44AM +0100, Christian Jaeger wrote: I just wanted to point it out here, since I wasn't sure whether I should file a bug report against fakeroot for writing suid through, I consider it a bug; it's introducing a third permissions+ownership state that was requested by neither the author nor the builder of the package. e.g. A program may be safe to run setgid games, but i certainly don't want it setgid to my project group. The package didn't ask for it to be setgid to my project group, so it's not wrong; I didn't ask for it; so it's a fakeroot bug. IMHO. Nor is it s[ug]id specific; if fakeroot is setting on-disk ownerships different to those requested, it should be pessimistic and not grant any actual permissions to those on-disk files. Permissions and ownerships only make sense together. or one for dpkg-buildpackage either for not mentioning the risk in the manpage, or for not warning that the directory I'm using is world accessible, or one for the debhelper scripts (? or? I don't know the build process enough) for not creating the tmp folders 0700. It could be worse, most rpm's seem to build in 777 directories. Build processes just aren't safe to run in publicly accessible dirs. But this does not excuse fakeroot to make up its own perms. -- Colin Phipps PGP 0x689E463E http://www.netcraft.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
On Tue, Jan 22, 2002 at 11:42:49AM +, Colin Phipps wrote:
On Tue, Jan 22, 2002 at 01:59:44AM +0100, Christian Jaeger wrote:
I just wanted to point it out here, since I wasn't sure whether I
should file a bug report against fakeroot for writing suid through,
I consider it a bug; it's introducing a third permissions+ownership
state that was requested by neither the author nor the builder of the
package.
snip
So file some bugs about it. Start with debhelper, and have
debian/{tmp,$package} directories made 0700, then lintian, and when
it's become generally accepted, propose an amendment to policy.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ | Dept. of Computing,
`. `' | Imperial College,
`- -- | London, UK
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
On Tuesday, 2002-01-22 at 01:11:18 +0100, Christian Jaeger wrote: (BTW a somewhat similar problem (but not debian specific) exists with the perl CPAN module build process: -MCPAN is designed to work as root. It downloads the tarball, extracts it (with the user/group that the author packed them) as root, thus you are left with files belonging to random system users. -MCPAN doesn't take any precautions to protect the .cpan/build/ folder, thus with a bit luck some user on the system can modify the unpacked files before they are built/installed by root.) You do not need to run the CPAN build process as root. You *mey* need the root account to install the packages (which, I admit, is conveniently done from the CPAM.pm module). Now, if your site specific CPAN directories do not belong to root, you don't need even that. However, if then other perl library directories *are* owned by root, you have trouble with new versions of Perl Core modules - perl will always pick the old ones in the system library directories because of the standard @INC. Should those directories be owned by a perl owner use in Debian to prevent possible exploits from Perl modules? It's easy to catch somebody unawares from a Makefile.PL. Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm|
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
On Tue, Jan 22, 2002 at 01:59:44AM +0100, Christian Jaeger wrote: I just wanted to point it out here, since I wasn't sure whether I should file a bug report against fakeroot for writing suid through, I consider it a bug; it's introducing a third permissions+ownership state that was requested by neither the author nor the builder of the package. e.g. A program may be safe to run setgid games, but i certainly don't want it setgid to my project group. The package didn't ask for it to be setgid to my project group, so it's not wrong; I didn't ask for it; so it's a fakeroot bug. IMHO. Nor is it s[ug]id specific; if fakeroot is setting on-disk ownerships different to those requested, it should be pessimistic and not grant any actual permissions to those on-disk files. Permissions and ownerships only make sense together. or one for dpkg-buildpackage either for not mentioning the risk in the manpage, or for not warning that the directory I'm using is world accessible, or one for the debhelper scripts (? or? I don't know the build process enough) for not creating the tmp folders 0700. It could be worse, most rpm's seem to build in 777 directories. Build processes just aren't safe to run in publicly accessible dirs. But this does not excuse fakeroot to make up its own perms. -- Colin Phipps PGP 0x689E463E http://www.netcraft.com/
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
Andrew Suffield wrote:
On Tue, Jan 22, 2002 at 11:42:49AM +, Colin Phipps wrote:
On Tue, Jan 22, 2002 at 01:59:44AM +0100, Christian Jaeger wrote:
I just wanted to point it out here, since I wasn't sure whether I
should file a bug report against fakeroot for writing suid through,
I consider it a bug; it's introducing a third permissions+ownership
state that was requested by neither the author nor the builder of the
package.
snip
So file some bugs about it. Start with debhelper, and have
debian/{tmp,$package} directories made 0700, then lintian, and when
it's become generally accepted, propose an amendment to policy.
I doubt I'd accept such a bug. It looks like a misdesign of fakeroot,
and should be fixed in fakeroot. I agree with Colin Phipps's message
entirely.
--
see shy jo
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
also sprach Christian Jaeger [EMAIL PROTECTED] [2002.01.22.0111 +0100]: Now you may say don't build packages as root, use fakeroot instead. Well I have always used it, and somehow thought I'm safe, but I'm not: the permissions modes (like 4755) make it through to the real filesystem, only the owner/group is faked. Thus I'm left with binaries setuid *me* or setgid *my group* afterwards. That's only slightly better than root, since I'm also the admin and once my account is hijacked it's not far from being root. why are your build directories accessible to the world? a simple chmod 0700 ~/deb/build fixes all these problems for me, and persistently... It seems the only way around this (currently) is to compile packages in a directory with 0700 permissions. and? what's so wrong with that? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck it appears that pl/i (and its dialects) is, or will be, the most widely used higher level language for systems programming. -- j. sammet msg05475/pgp0.pgp Description: PGP signature
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
At 1:19 Uhr +0100 22.01.2002, martin f krafft wrote: why are your build directories accessible to the world? a simple chmod 0700 ~/deb/build fixes all these problems for me, and persistently... They were accessible, because I didn't realize that there was a risk, and because it's convenient when other users on the system can grab the finished .deb's from the build dir (to install them on their machine) without me having to move them to a public place. Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
also sprach Christian Jaeger [EMAIL PROTECTED] [2002.01.22.0129 +0100]: They were accessible, because I didn't realize that there was a risk, and because it's convenient when other users on the system can grab the finished .deb's from the build dir (to install them on their machine) without me having to move them to a public place. yes, that's UNIX life. convenience ~ security^-1, where operator~ here is proportional -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck i have the power to channel my imagination into ever-soaring levels of suspicion and paranoia. msg05479/pgp0.pgp Description: PGP signature
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
yes, that's UNIX life. convenience ~ security^-1, I just wanted to point it out here, since I wasn't sure whether I should file a bug report against fakeroot for writing suid through, or one for the fakeroot manpage not mentioning the danger, or one for dpkg-buildpackage either for not mentioning the risk in the manpage, or for not warning that the directory I'm using is world accessible, or one for the debhelper scripts (? or? I don't know the build process enough) for not creating the tmp folders 0700. chj.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
For the non-mathmatical, or rather gramatical, style to say it, I use the phrase: Security is Inconvenient. The first time I say it to someone, they usually pause for a moment, digest it, and it really helps in further discussions about what to do about It's my answer, for instance, when someone notices just how much I type to open an SSH session. Wow, that's a long password. Yep, security is inconvenient. Sometimes this leads to *their* inquiring as to what it buys, and leads to another informed user who doesn't feel pressured. It isn't just UNIX, have you ever looked at how every openable thing on a Catarpiller earth-moving machine has a way to padlock it closed? One key for simple operation, another key for routine engine maintenance, maybe a pass-key (su) for the shop forman, etc... Curt- -Original Message- From: martin f krafft [mailto:[EMAIL PROTECTED]] ... yes, that's UNIX life. convenience ~ security^-1, where operator~ here is proportional -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck i have the power to channel my imagination into ever-soaring levels of suspicion and paranoia. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
On Tue, Jan 22, 2002 at 01:11:18AM +0100, Christian Jaeger wrote: This can be a real security hole, at least when you are not aware of it (I have just discovered a working way to exploit it on one of my machines). And isn't that a bug in the package in question? :) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
also sprach Christian Jaeger [EMAIL PROTECTED] [2002.01.22.0129 +0100]: They were accessible, because I didn't realize that there was a risk, and because it's convenient when other users on the system can grab the finished .deb's from the build dir (to install them on their machine) without me having to move them to a public place. yes, that's UNIX life. convenience ~ security^-1, where operator~ here is proportional -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] i have the power to channel my imagination into ever-soaring levels of suspicion and paranoia. pgpvyzvwUVPlk.pgp Description: PGP signature
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
yes, that's UNIX life. convenience ~ security^-1, I just wanted to point it out here, since I wasn't sure whether I should file a bug report against fakeroot for writing suid through, or one for the fakeroot manpage not mentioning the danger, or one for dpkg-buildpackage either for not mentioning the risk in the manpage, or for not warning that the directory I'm using is world accessible, or one for the debhelper scripts (? or? I don't know the build process enough) for not creating the tmp folders 0700. chj.-
