Hi, Ivan. On Wed, 12 Jan 2005, Ivan M. wrote: >Thanks to the prompt help of Peter Stuge, I easily managed to resolve >the problems with my own version of the CHECKPASSWD stub. However, >after a little thought, even though the problems were of my own making >they do raise a couple of security issues in my mind. >First, programs like bincIMAPd which normally run on behalf of a user >should never run as root, even accidentally. In the first version of my >password stub, I assumed that bincIMAPd still required root privileges >and would drop them as soon as possible (which is standard practice). >So, I didn't set the user or group id's and, later, the daemon created >the mailbox with owner root.
bincimapd has no concept of users or groups; it's not bincimapd's job to act as an authority there. bincimap-up does, but it's perfectly fine to run bincimapd as root. If you want to prevent this, you can either modify bincimapd, or introduce a script which wraps bincimapd, first checking if you are running as root. Binc IMAP is very flexible in this sense. Example: #!/bin/bash test `whoami` == 'root' && exit 111 exec $@ Sysadmins who want to read their root mail can use bincimapd for that. If you are concerned about security, you forward your root mail to another user. >Second, security conscious programs should not rely on the current >working directory (cwd), they should use absolute paths to their >configuration and data files (this, too, is standard practice). It just >never occurred to me that a server would assume a valid working directory >instead of setting the path itself from /etc/password or, at the least, >from the HOME variable. It's not a server in that sense, and the way checkpassword works is that checkpassword chooses the current working directory, and Binc IMAP uses this. It's the design of checkpassword. And for configuration files, Binc IMAP will not refuse admins from using relative paths in bincimap.conf. >On an insecure system it would be relatively easy to subvert >CHECKPASSWORD in order to silently read mail belonging to someone else, >especially since the program is stored by default in /bin instead of >/sbin. I'm not saying this is likely, and I'm not going to give any >clues on how to do it, but it is possible. Making these two fairly minor >changes would completely eliminate two well-known classes of potential >attack. 1) The difference between /bin/ and /sbin/ from a security standpoint is zip. 2) When you're saying it's possible to break checkpassword, I totally agree. So maybe the docs should mention that you should never allow your checkpassword implementation to change to root, and that you can wrap bincimapd to prevent it being invoked as root. >Even so, I'm happy to have found bincIMAP. It neatly fits our needs much >better than the other well known IMAP servers. Thank you, Andreas, for >all your hard work. Thanks! Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
