linux-kernel - Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Apr 2008 09:45:22 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Crispin Cowan <crispin@...spincowan.com>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Matthew Wilcox <matthew@....cx>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	paul.moore@...com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, takedakn@...data.co.jp,
	linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

Crispin Cowan wrote:
> Of *course* AppArmor protects the integrity of /etc/shadow, and 
> unauthorized parties are not permitted to feed data into that file 
> unless explicit access is granted. The difference is in how it is done:
> 
>    * SELinux marks the inode with a label, and only processes with the
>      right permissions can mess with the label.
>          o Residual problem: someone could rename the inode and drop a
>            new inode into place named "/etc/shadow". SELinux addresses
>            this with access control on the parent directory.

<small> I have actually hacked a system by renaming /etc/passwd in
this way.  /etc was owned by user "bin", and I had a login as "bin"
due to a misfeature in some program.  So I substituted another
/etc/passwd, and gave myself a root shell. </small>

The trouble with access control on the parent directory is that
occasionally some human accidentally forgets how important that is,
thinking that permissions on the /etc/shadow file are important.

Also *programs* care about a file with that name.  They reference it
by name, apply security decisions based on a process which starts with
that name.  So the name is the most relevant point of communication
between the policy setter and programs which need to be affected.

So I think AppArmor's approach is good here.

>    * AppArmor checks the name "/etc/shadow" so that you cannot access
>      that name without explicit permission.
>          o AppArmor cares about the integrity of what the OS returns
>            when you access the name "/etc/shadow" and does not care a
>            wit what happens to the inode that was *previously* named
>            "/etc/shadow".
> 
> Now, without running off into the weeds again, tell me again why I 
> should care about the *integrity* of an inode that was *previously* 
> known as "/etc/shadow"?

But insufficient here.

If you rename /etc/shadow legitimately, after changing a password,
there might be a program which still has a handle to the _old_ inode
and is still reading it, still comparing a password against its contents.

If policy was entirely name based, so modifications may be possible to
that file after it's renamed from /etc/shadow to /etc/shadow.bak,
_while_ some programs are still reading it (because it was /etc/shadow
when they opened it, and they got swapped for a moment), that's a failure.

So you *should* care about the integrity of an inode that was
previously known as /etc/shadow - at least until you can prove that
nobody is still dependent on it's earlier security properties.  That's
a garbage collection problem.

> So associating a security property with a name is ok if you do it 
> statically at some arbitrary point in time, but not if you consider it 
> at the time of access? WtF? Isn't that a gigantic race condition?

Both are race conditions.

> To the contrary, I argue that the *current* name of a file is vastly 
> more meaningful for security properties than the name the file had some 
> months ago when someone ran restorecon over the file system.

I agree that the current name is meaningful, but it's not watertight
when your systems change.  To avoid unexpected weaknesses, you'll need
to apply the intersection of permissions over a time period, using
name based policy but having it follow renames until you can prove
it's safe to release the following.

-- Jamie
--
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/