Menu
▾
▴
fetchmail-devel
|
From: Thomas J. <tho...@in...> - 2009-03-27 17:40:56
Attachments:
fetchmail-6.3.9-drop-privs.patch
|
Hello together, attached is a patch which allows fetchmail to drop root privileges and run inside a chroot. The idea is to read the config file as root (as it contains passwords) and setup the logging. The root privileges get dropped after initialization. All new features are optional. This will leave a stale lockfile after the fetchmail run (not enough privileges to write to /var/run or even not accessible inside the chroot), fetchmail perfectly handles that on the next invocation. Upstream integration or feedback is welcome :-) The patch is against fetchmail 6.3.9. Have a nice weekend, Thomas |
|
From: Thomas J. <tho...@in...> - 2009-04-22 15:06:46
|
On Friday, 27. March 2009 17:14:02 Thomas Jarosch wrote: > Upstream integration or feedback is welcome :-) > The patch is against fetchmail 6.3.9. Any comment on the patch? Regards, Thomas |
|
From: Matthias A. <mat...@gm...> - 2009-04-22 18:22:58
|
Thomas Jarosch schrieb: > Hello together, > > attached is a patch which allows fetchmail to drop root privileges > and run inside a chroot. The idea is to read the config file as root (as it > contains passwords) and setup the logging. The root privileges get dropped > after initialization. > > All new features are optional. This will leave a stale lockfile after > the fetchmail run (not enough privileges to write to /var/run or even > not accessible inside the chroot), fetchmail perfectly > handles that on the next invocation. > > Upstream integration or feedback is welcome :-) > The patch is against fetchmail 6.3.9. > > Have a nice weekend, > Thomas Hi Thomas, sorry for not giving immediate feedback - I've been busy with other things, among them real life and also leafnode releases... At first glance, the patch looks sound, thanks a lot. There's some point in integrating such functionality inside fetchmail, i. e. keeping sensitive data outside fetchmail's accessible area. We'd probably need more detailed instructions of what doesn't work inside chroots (you mentioned /var/run -- and this may require revising the stale lock detection and/or logging), and what needs to be inside the chroot because it's re-read at run-time, for instance, the resolver is re-initialized frequently in daemon mode, so we need some libs and config files inside the chroot, and depending on how much caching the libc does, we may need f. i. /etc/services... unfortunately, this is highly OS and version dependent. I still need to think how to integrate all this, since 6.3.X is supposed to be a bug-fix branch... it seems I need to revive the bit-rotten 6.4.X branch for new features, mark 6.3 "regression fixes only" and move on... I'm also pondering whether fetchmail needs a split-process model some day, which might then solve issues such as the /var/run (PID file) removal problem you mentioned and perhaps allow for a pool of concurrent fetch children - useful with multiple accounts. That's certainly for later... Best Matthias |
|
From: Thomas J. <tho...@in...> - 2009-04-28 11:58:09
|
Hello Matthias, On Wednesday, 22. April 2009 18:22:57 Matthias Andree wrote: > We'd probably need more detailed instructions of what doesn't work inside > chroots (you mentioned /var/run -- and this may require revising the stale > lock detection and/or logging), and what needs to be inside the chroot > because it's re-read at run-time, for instance, the resolver is > re-initialized frequently in daemon mode, so we need some libs and config > files inside the chroot, and depending on how much caching the libc does, > we may need f. i. /etc/services... unfortunately, this is highly OS and > version dependent. If someone uses the daemon mode inside the chroot, I guess /etc/fetchmailrc needs to be owned by the unprivileged user, too. Though I don't use the daemon mode myself. My current chroot sandbox looks like this: [root@intranator fetchmail]# ls -alR .: total 5 drwxr-xr-x 2 root root 1024 Apr 24 16:03 etc drwxr-xr-x 2 root root 1024 Apr 24 16:00 lib drwxr-x--- 2 fetchmai fetchmai 1024 Apr 24 11:59 tmp ./etc: total 18 -rw-r--r-- 1 root root 26 Apr 24 16:03 host.conf -rw-r--r-- 1 root root 48 Apr 24 16:03 hosts -rw-r--r-- 1 root root 837 Apr 24 16:03 localtime -rw-r--r-- 1 root root 34 Apr 24 16:03 resolv.conf -rw-r--r-- 1 root root 11375 Apr 24 16:03 services ./lib: total 1264 -rwxr-xr-x 1 root root 218749 Nov 2 2004 libnss_compat-2.1.3.so lrwxrwxrwx 1 root root 22 Apr 24 16:00 libnss_compat.so.2 -> libnss_compat-2.1.3.so -rwxr-xr-x 1 root root 68957 Nov 2 2004 libnss_dns-2.1.3.so lrwxrwxrwx 1 root root 19 Apr 24 16:00 libnss_dns.so.2 -> libnss_dns-2.1.3.so -rwxr-xr-x 1 root root 245542 Nov 2 2004 libnss_files-2.1.3.so lrwxrwxrwx 1 root root 21 Apr 24 16:00 libnss_files.so.2 -> libnss_files-2.1.3.so -rwxr-xr-x 1 root root 69129 Nov 2 2004 libnss_hesiod-2.1.3.so lrwxrwxrwx 1 root root 22 Apr 24 16:00 libnss_hesiod.so.2 -> libnss_hesiod-2.1.3.so -rwxr-xr-x 1 root root 255929 Nov 2 2004 libnss_nis-2.1.3.so lrwxrwxrwx 1 root root 19 Apr 24 16:00 libnss_nis.so.2 -> libnss_nis-2.1.3.so -rwxr-xr-x 1 root root 254328 Nov 2 2004 libnss_nisplus-2.1.3.so lrwxrwxrwx 1 root root 23 Apr 24 16:00 libnss_nisplus.so.2 -> libnss_nisplus-2.1.3.so -rwxr-xr-x 1 root root 169644 Apr 24 16:00 libresolv-2.1.3.so lrwxrwxrwx 1 root root 18 Apr 24 16:00 libresolv.so.2 -> libresolv-2.1.3.so > I still need to think how to integrate all this, since 6.3.X is supposed to > be a bug-fix branch... it seems I need to revive the bit-rotten 6.4.X > branch for new features, mark 6.3 "regression fixes only" and move on... Put it in 6.4.x if you like, it works fine for me in 6.3. > I'm also pondering whether fetchmail needs a split-process model some day, > which might then solve issues such as the /var/run (PID file) removal > problem you mentioned and perhaps allow for a pool of concurrent fetch > children - useful with multiple accounts. That's certainly for later... So much ideas - so little time :-) Cheers, Thomas |
|
From: Sunil S. <sh...@bo...> - 2009-04-28 14:30:11
|
Hi Thomas Jarosch,
Quoting from Thomas Jarosch's mail on Fri, Mar 27, 2009:
> attached is a patch which allows fetchmail to drop root privileges
> and run inside a chroot. The idea is to read the config file as root (as it
> contains passwords) and setup the logging. The root privileges get dropped
> after initialization.
>
> All new features are optional. This will leave a stale lockfile after
> the fetchmail run (not enough privileges to write to /var/run or even
> not accessible inside the chroot), fetchmail perfectly
> handles that on the next invocation.
>
> Upstream integration or feedback is welcome :-)
> The patch is against fetchmail 6.3.9.
Here are some thoughts on the options in your patch.
The run_chroot option:
The patch does not handle files which are being opened after chroot.
Any file opened after the chroot will be in the wrong location. For
example, in this invocation with your patch:
# fetchmail --run_chroot /home/user --logfile /home/user/fetchmail.logs \
--idfile /home/user/.fetchids --bsmtp /home/user/bsmtp.file \
--preconnect '/home/user/preconnect.py script-arguments'
the logfile is being opened before the chroot, the bsmtp file is being
opened after the chroot (i.e. /home/user/home/user/bsmtp.file), and
the idfile is being opened before the chroot for reading *and* after
the chroot for writing! The preconnect script is running in the
chroot.
Your patch will work correctly only if fetchmail does not open any
file or run any script after the chroot.
Also, ensuring that the preconnect script runs properly in the chroot
will be next to impossible.
The run_user and run_group options:
fetchmail is essentially a user-level daemon program. Unlike a system
daemon, it does not require special privileges to read the
configuration files and it does not bind to a reserved port. So, it is
far simpler to start fetchmail with a command like:
# su user -c fetchmail
rather than
# fetchmail --run_user user
Is it really useful to have passwords in a root-owned file? Does it
add to security? In case you really want that, you may run fetchmail
in this fashion as root:
# su user -c fetchmail -f - < /etc/fetchmailrc
The added advantage is that the lockfile is the correct place.
Another problem will be that if /etc/fetchmailrc is modified after
fetchmail is invoked with the --run_user option, it will detect the
file modification and exit because the file cannot be read again due
to dropping of privileges. Try this:
# fetchmail --run_user user --daemon 1800
[ wait for one poll to complete ]
# touch /etc/fetchmailrc
# fetchmail
This will not happen with the invocation with redirection!
--
Sunil Shetye.
|
|
From: Thomas J. <tho...@in...> - 2009-04-30 11:13:52
|
Hello Sunil, > Here are some thoughts on the options in your patch. Thanks for your review! > The run_chroot option: > ... > Your patch will work correctly only if fetchmail does not open any > file or run any script after the chroot. > > Also, ensuring that the preconnect script runs properly in the chroot > will be next to impossible. Yes, that is true. > The run_user and run_group options: > > fetchmail is essentially a user-level daemon program. Unlike a system > daemon, it does not require special privileges to read the > configuration files and it does not bind to a reserved port. So, it is > far simpler to start fetchmail with a command like: > > # su user -c fetchmail > > rather than > > # fetchmail --run_user user > > Is it really useful to have passwords in a root-owned file? Does it > add to security? In case you really want that, you may run fetchmail > in this fashion as root: > > # su user -c fetchmail -f - < /etc/fetchmailrc > > The added advantage is that the lockfile is the correct place. > > Another problem will be that if /etc/fetchmailrc is modified after > fetchmail is invoked with the --run_user option, it will detect the > file modification and exit because the file cannot be read again due > to dropping of privileges. Try this: > > # fetchmail --run_user user --daemon 1800 > [ wait for one poll to complete ] > # touch /etc/fetchmailrc > # fetchmail > > This will not happen with the invocation with redirection! Interesting approach with the redirection, didn't think of it before. We don't run fetchmail in daemon mode, we start it for a single run as it doesn't know if the online connection is available or if the mail system is currently reconfigured on our site. Basically fetchmail is controlled by another daemon. The new features are completly optional and allow you to harden the security in basic setups if running in non-daemon mode. If the normal fetchmail usage is the daemon mode, then I guess it's not very useful. Hmm. Cheers, Thomas |
|
From: Sunil S. <sh...@bo...> - 2009-04-30 13:05:18
|
Hi Thomas, Quoting from Thomas Jarosch's mail on Thu, Apr 30, 2009: > We don't run fetchmail in daemon mode, we start it for a single run > as it doesn't know if the online connection is available or if the > mail system is currently reconfigured on our site. Basically fetchmail > is controlled by another daemon. You may still run fetchmail in daemon mode with a high poll interval: $ fetchmail --daemon 86400 # poll just once a day ... Whenever you are online, just wake it up: $ fetchmail # ... or more > The new features are completly optional and allow you to harden > the security in basic setups if running in non-daemon mode. Unfortunately, the sandbox is not going to work in two common setups even in non-daemon mode: 1. POP3+UIDL: the idfile is read from /home/user/.fetchids and will be written back to /sandbox/home/user/.fetchids. In effect, the idfile is not getting updated at all! 2. MDA: this delivery program (like maildrop, procmail, or even a user-defined script) is not going to work in the sandbox. > If the normal fetchmail usage is the daemon mode, > then I guess it's not very useful. Hmm. Well, you too should try using the daemon mode... -- Sunil Shetye. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X