linux-kernel - new_inode_smack() bogosities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20120104221335.GF23916@ZenIV.linux.org.uk>
Date:	Wed, 4 Jan 2012 22:13:35 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: new_inode_smack() bogosities

1) in smack_sb_kern_mount()
        isp = inode->i_security;
        if (isp == NULL)
                inode->i_security = new_inode_smack(sp->smk_root);
        else   
                isp->smk_inode = sp->smk_root;
looks very fishy.  How in hell had that inode managed to get created
in the first place without going through smack_inode_alloc_security()?
Is that about mounting an fs instance with in-core superblock that
is older than the call of smack_init()?  That shouldn't be possible due
to initcall ordering, but if that's the case, just what would happen when
we step on *other* inodes on the same fs?  There's a bunch of places where
smack assumes that ->i_security is never NULL...  And if that's really
impossible, WTF is that new_inode_smack() doing there?

2) again in smack_sb_kern_mount()
        spin_lock(&sp->smk_sblock);
        if (sp->smk_initialized != 0) {
                spin_unlock(&sp->smk_sblock);
                return 0;
        }
        sp->smk_initialized = 1;
        spin_unlock(&sp->smk_sblock);
For one thing, security_sb_kern_mount() is serialized by sb->s_umount.
For another, if it wouldn't be... this code wouldn't be able to prevent
a race.  Sure, only one of them will proceed to initialize the sucker.
And another may cheerfully return before the work is actually done...
In any case, it *is* serialized on per-superblock basis.

3) in smk_fill_super(), we have
        root_inode = sb->s_root->d_inode;
        root_inode->i_security = new_inode_smack(smack_known_floor.smk_known);
Again, huh?  This should be called after smack_init() had been done; hell, 
you explicitly say so in the comments:
 * Do not register smackfs if Smack wasn't enabled
 * on boot. We can not put this method normally under the
 * smack_init() code path since the security subsystem get
 * initialized before the vfs caches.
Sounds like a misspelled assignment to ->smk_inode to me (and a leak, while
we are at it)...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/