The command "chmod +s /path/to/file", is another way of writing "chmod u+s,g+s /path/to/file" or "chmod ug+s /path/to/file", some developers seem to think it means "chmod u+s /path/to/file", although sgid permissions don't get as much press as suid permissions, it is still a security issue and _must_ not be handed out liberally. In fact, many application developers who design their apps to run suid drop privileges or call setuid() before allowing the user to do anything like open files or execute programs, this _will not_ drop group privileges, so only applications that specifically need sgid should be given it. They _can_ be a security risk, such as allow reading the sudoers file, bypassing quota limits, accessing devices that allow group r/w, the obvious bypassing group restrictions and group privilege escalation, etc. Being bored earlier today, i decided to do a rough audit of the applications that contain "chmod +s" in stable ebuilds :) kde-base/arts -- a quick look through shows the application runs setgid(getgid()) before executing the crashhandler, which was my first idea....but maybe there's another way to exec stuff or write to files. app-crypt/newpg -- **exploitable**, it took me just a few minutes to work out how to access /etc/sudoers, using gpgsm --encrypt --recipient YOURID --output foobar /etc/sudoers, decrypt the foobar file and you have a plain text copy of /etc/sudoers. can also create files owned by group root, and write to group root writable devices, etc. kde-base/kdenetwork -- didn't have time to compile all of the kde deps, but it doesnt look like it really needs sgid, if someone has kde installed maybe they can have a quick look to see if it can open/exec/write files? (eg, a --output --exec etc.) sys-fs/lufs and media-video/avifile -- both of these advise users to run chmod +s. this should probably be changed to advise chmod u+s, avifile can fairly obviously be used to read/write to group root owned files.
Ok looking at app-crypt/newpg I can see a few things I also dislike about it. It lacks metadata.xml We make a blind assumption that it should be +s even though the package itself does not install itself this way. (We should have a policy to disallow this.) A newer versions exists. The original dev that committed the ebuild is no longer active? ... Are we cool with me bumping this to the newest version and completely dropping the +s bit all together? However reading this. ftp://ftp.gnupg.org/gcrypt/alpha/aegypten/newpg-latest.README newpg is not anymore supported; please use gnupg-1.9.x - or if available gnupg-2.x. So if we wanted it sounds like it could just be dropped.
Created attachment 39776 [details, diff] newpg-0.9.4-r1.ebuild.diff Actually this package wont even compile for me. gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -pipe -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'maperror.c' || echo './'`maperror.c maperror.c: In function `map_ksba_err': .. (spews a bunch of undefined references to XXX symbols.) -------------------------------------------------- newpg-0.9.5 is moot. It's just a README+NEWS file. NewPG is a temporary protect to work on GnuPG extensions. It will be merged into the regular GnuPG sources for a GnuPG 2.0 release. ==> NOTE: NewPG is dead and has been superseded by GnuPG > 1.9 <== -------------------------------------------------- Anyway see as it wont even compile here I'm thinking some other dev can fix it. Here is a suggested diff.
Created attachment 39777 [details, diff] newpg-0.9.4-r1.ebuild.diff update to add missing inherit flag-o-matic
So we have three affected packages, and two that might need to update their advice. On newpg, I would drop the beast. It's an obsolete package and it has no maintainer anyway. Calling in other packages maintainers to discuss the need for chmod +s vs u+s in their packages.
[Original newpg package committer here...] I agree that newpg should be removed, given that it is deprecated and contains security holes. - Robert
newpg removed from the tree.
what's the recommendation then on the kde packages? arts suid bit is only set if you have a use flag, so that seems fairly safe to me. i don't know about the kdenetwork sgid bit and it's effect.
Security recommendation is : 1- don't use chmod +s at all if it can work without it 2- use chmod u+s when it's needed, but g+s is not needed 3- use chmod ug+s if it's really needed Reporter's point is that some ebuilds might have "chmod +s" because maintainers think it's equivalent to "chmod u+s", while they don't really need the sgid bit. The idea is to check the necessity of the g+s on packages that have it, and make sure it wasn't set by mistake using the shortcut "chmod +s". For arts and kdenetwork : are they installed the same way (with ug+s) on all distributions ? Or was the g+s set by mistake by Gentoo's ebuilds ?
4- use go-r when possible.
I don't really like that newpg has gone away. It is the only package providing gpg-agent which is not masked. (Don't worry, I have a local ebuild anyway with some local changes) Gpg-agent is necessary to use gpg signing with the aegypten stuff in kmail. I know that gpg-agent does not compile with newer (alpha) versions of libcrypt etc.
gnupg-1.9.x is not masked, it's in unstable but your point is that current Gentoo stable lacks a gpg-agent now
It is masked in current cvs [package.mask]: # <taviso@gentoo.org> (06 Jan 2004) # alpha branch of gnupg. >=app-crypt/gnupg-1.9.0 # <dragonheart@gentoo.org> (27 Aug 2004) # Masked due to gnupg-1.9 >=app-crypt/gpgme-0.9.0-r20
since the latest versions of gnupg are still unstable and hard masked in portage, would it be possible to have an ebuild for gpg-agent that builds newpg but only installed the gpg-agent binaries? I think it's important to have a stable ebuild in place with gpg-agent since so many people I'm sure are going to be looking for it (I know it took me some time to find it initially) Or are you guys planning on making stable some of the gnupg packages so people can install gpg-agent that way? I noticed the kdepim-3.3.0-r1 ebuild depends on gnupg >=0.9.0, and built it last night, but I'm not at work so I haven't had a chance to check to see if it worked. gpg-agent was giving me some errors, but kmail apparently needed to be rebuilt against the new version of gpgme... basically, what I'm concerned with is my own use of kmail with gpg-agent, and making accurate my document about how to set up kmail with gpg-agent for signing/encrypting purposes located here http://gentoo-wiki.com/HOWTO_Kmail_gpg-agent_kde I greatly encourage the use of gpg/pgp for privacy and email confirmation needs, and I think that having a good document that makes it easy to set up is quite good to have and can help spread the growth of gpg use :) Anyways, I'm done rambling.. if any activity goes on regarding gpg-agent and kmail, if someone could remember to put me in the CC list that would be excellent. Also, if there's anythingI can do to help (testing, documentation, etc) please feel free to contact me. Thank you :) -Jeremy
Pulling in crypto herd for an answer on the last comment. KDE : in arts : use artswrappersuid && chmod +s ${D}/${PREFIX}/bin/artswrapper "chmod +s" is, as you said, protected by a very specific 'artswrappersuid' flag... but it probably should be "chmod u+s" and not "chmod +s", since I don't think the SGID is needed. in kdenetwork : chmod +s ${D}/${KDEDIR}/bin/reslisa There it's *not* protected by a flag and it probably should also be "chmod u+s" rather than "chmod +s". resLisa needs the SUID, but not the SGID (I think). In both cases I don't think it's exploitable, but better safe than sorry.
will plan to fix kde for 3.3.1, due out next week.
crypto herd : any solution to the "no more gpg-agent" issue ?
I see kde 3.3.1 is now in portage.. any ideas on if gpg-agent or something that will work with kmail for caching passphrases etc will be available? I plan to see if kde's wallet can do this, but I don't believe so.
The latest net-misc/keychain supports a gpg agent. I have't played with it yet.
fixed in arts-1.3.1 - removing kde
We're done here from a security point of view. If a gpg-agent is still missing in Gentoo stable, please file another bug that will be more clearly dedicated to solving this problem.
