OSEC

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

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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 majordomopostfix.org with content
    (not subject): unsubscribe postfix-users