|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Alex van den Bogaerdt (alex_at_ergens.op.HET.NET)
Date: Sun Jul 28 2002 - 09:12:06 CDT
Wietse Venema wrote:
>
> Can you show why this actually satisfies the requirements? The text
> is vague about mail spool permissions and process privileges.
I tried to do so but obviously I am not clear enough. Please tell
me what you think isn't clear enough and I will clarify case by case.
> For example, the step that changes maildir directory ownership to
> the recipient is a critical step. What prevents a subverted non-root
> user (postfix or otherwise) from tricking Postfix into changing
> ownership of an object that is specified by an attacker?
The trick is that postfix will only change the ownership if the
mkdir(2) command succeeded. mkdir(2) will only be called if there
is no directory present. Even if there is something present, such
as a file, directory or symlink, mkdir(2) will fail and thus the
excercise is aborted --> no chown(2)
> To give you an idea, see the safe_open.c module that tries to solve
> a similar problem with files instead of directories.
I think this situation is completely different:
mkdir(2) already acts like open(2) with O_CREAT and O_EXCL set.
The directory should be one we can trust. This is done by checking
that it actually is $mail_spool_directory (something that is selected
by the owner of the system) and has the right permissions (owned by root,
not globally writable and so on).
The proposed way of creating the directory makes sure no process will
enter/use/link_to the directory before we're finished. Only a process
already having root privileges will be able to trick postfix into doing
something wrong and of course it then wouldn't need postfix.
cheers,
Alex
-
To unsubscribe, send mail to majordomo
postfix.org with content
(not subject): unsubscribe postfix-users
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]