pkg-install messed up perm and owner/group of ${PREFIX}/lib/sguil-server. "install -o sguild -g sguild -m 0750" is not something you expect in lib directory. Port maintainer (pauls@utdallas.edu) is cc'd. Generated with FreeBSD Port Tools 0.77
Maintainer of security/sguil-server, Please note that PR ports/124257 has just been submitted. If it contains a patch for an upgrade, an enhancement or a bug fix you agree on, reply to this email stating that you approve the patch and a committer will take care of it. The full text of the PR can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/124257 -- Edwin Groothuis via the GNATS Auto Assign Tool edwin@FreeBSD.org
State Changed From-To: open->feedback Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
I don't see what the problem is. The pkg-install script section to which you refer is optional. Furthermore, it warns you that it creates user and group accounts named sguil. The only time the directories will change user and group ownership and perms is if you choose to run the script. I also fail to see how the perms used create a problem. If you choose to run sguil as root, there's no problem. If you choose to run sguil as some other user, then you *should* opt out of that portion of the script. Worst case scenario you simply change the permissions to what you want after you install. I looked for some guidance in hier (7) to see if there was a required protocol for perms on directories but didn't find one. Perhaps you can point me to something that says the perms assigned by the script are incorrect. Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
I don't have any pointer to proper permission of lib directory. However, I'll show you some facts. The following command shows nothing on my hosts (FreeBSD, OpenBSD and Gentoo/Linux). My laptop has more than 1,500 ports installed. > find /usr/local/lib -type d -perm 750 The next one shows the current ports tree doesn't have any port which installs anything into ${PREFIX}/lib with 750. Of course, the regex isn't perfect (it misses ${INSTALL} in multiple lines, ports like yours which doesn't use ${MACRO} provided by the ports framework and various other reasons). However, if you find a port which uses 0750 as permission for lib directory, let me know. I'm happy to submit another PR. > ack -a '\${INSTALL}.*-m\s+\d?7\d{2}\s.*\${PREFIX}/lib[^ed]' /usr/ports/ /usr/ports/databases/libudbc/Makefile 41: @${INSTALL} -c -o ${SHAREOWN} -g ${SHAREGRP} -m 755 ${WRKDIR}/udbcsdk/lib/libudbc.la ${PREFIX}/lib 42: @${INSTALL} -c -o ${LIBOWN} -g ${LIBGRP} -m 755 ${WRKDIR}/udbcsdk/lib/libudbc.so ${PREFIX}/lib /usr/ports/devel/linuxthreads/Makefile 216: ${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 0755 ${PREFIX}/lib /usr/ports/devel/linuxthreads/files/patch-aa 146:+ ${INSTALL} -d -o ${BINOWN} -g ${BINGRP} -m 0755 ${PREFIX}/lib /usr/ports/security/bsp_upektfmess/Makefile 54: ${INSTALL} -o root -m 0755 ${TFMESSPATH}/libtfmessbsp.so ${PREFIX}/lib NOTE: ${LIBOWN} is defined in /usr/share/mk/bsd.own.mk Thanks to 0750, findlibusers.py[1] doesn't work anymore when executed by an unprivileged user. You're free to say that its error handling is not robust enough, of courese. Also, locate(1) silently ignores any files under ${PREFIX}/lib/sguil-server. The user will find out that s/he is not supposed to assume that system lib directory is world-readable. I'm sure it breaks other things. 7[05]0 makes sense in some cases (mostly for security season), but not in this case. If you have a particular reason, I'd like to know. [1] http://www.maxlor.com/freebsd-scripts.shtml -- Tomoyuki Sakurai
Responsible Changed From-To: freebsd-ports-bugs->amdmi3 I'll take it.
> Synopsis: [PATCH] security/sguil-server: ${PREFIX}/lib/sguil-server has wrong perm, owner and group > > http://www.freebsd.org/cgi/query-pr.cgi?pr=124257 The questions to maintainer are: 1) Is there a reason for ${PREFIX}/lib/sguil-server to be non-world-readable? 2) Is there a reason for ${PREFIX}/lib/sguil-server to be owned by not root:wheel? If there are no real reasons for those, the directory should not be installed with nondefault ownerwhip/permissions. From what I see, it addition 1) breaks some utilites that may read /usr/local/lib and 2) may be a security issue, as software which is run with unpriviledged user credentials should not be able to alter sources of itself or its modules. The only possible reason I can see for 2) is that changing/adding/deleting files under ${PREFIX}/lib/sguil-server is intended behavior. If that is so, the directory should be located under /var in the first place. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
I just noticed this PR. Don't know how I lost track of it. Anyway, to answer your questions: 1) I thought I was following protocol. I actually modeled my pkg-install script off of the one in the sguid proxy port, which sets two directories to 750. There are a number of ports that use the perms 750 for various directories, particularly in pkg-install scripts. # grep -r 750 /usr/ports/* | grep -ic chmod 46 /usr/ports/comms/gnokii/pkg-install: chmod 750 ${BINS} /usr/ports/databases/frontbase/pkg-install: chmod 750 ${PKG_PREFIX}/FrontBase/Backups /usr/ports/databases/frontbase/pkg-install: chmod 750 ${PKG_PREFIX}/FrontBase/Databases /usr/ports/databases/frontbase/pkg-install: chmod 750 ${PKG_PREFIX}/FrontBase/TransactionLogs /usr/ports/devel/flyspray/files/pkg-install.in: %%CHMOD%% 750 %%ATTACHMENTDIR%% /usr/ports/devel/perforce/pkg-install: chmod 750 $PERFORCE_ROOT /usr/ports/games/mangband/Makefile: ${CHMOD} 750 ${MALIB}/* /usr/ports/irc/bopm/Makefile: @${CHMOD} 750 ${LOGDIR} /usr/ports/irc/inspircd/files/pkg-install.in: chmod 750 $etcdir /usr/ports/irc/ircd-ratbox/files/pkg-install.in:&& chmod 750 %%LOGDIR%% /usr/ports/irc/ircd-ratbox/files/pkg-install.in:&& chmod 750 %%RUNDIR%% /usr/ports/irc/ircd-ratbox/files/pkg-install.in: chmod 750 ${PKG_PREFIX}/etc/ircd-ratbox/ /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in:&& chmod 750 %%LOGDIR%% /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in:&& chmod 750 %%RUNDIR%% /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in:&& chmod 750 %%DBDIR%% /usr/ports/irc/ircd-ratbox-devel/files/pkg-install.in: chmod 750 %%PREFIX%%/etc/ircd-ratbox/ /usr/ports/irc/ratbox-services/files/pkg-install.in:&& chmod 750 %%DBDIR%% If that's incorrect, a lot more than this one need to be fixed. Having said that, I really don't care one way or the other, but I do think I need guidance, and some standard needs to be followed. 2) My answer for this is the same. I modeled the script after the squid pkg-install script, which makes the user:group of the process owner of the files. If this is incorrect behavior, I need to know that. No, the sguild user does not need to alter any of the files in ${PREFIX}/lib/sguil-server. If I need to change these things, I need to know pretty soon, because I'm working on a patch for the pkg-install script to fix a problem with package building. Sorry I didn't reply to you sooner. -- Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
State Changed From-To: feedback->closed Userland utilities that can't handle inaccessible directories during hierarchy traversing are not enough reason to just dump explicitly set restrictive permissions for a security tool. Custom scripts not for public eye may be placed into directory in question so there's reason for it to be non-world-readable.