linux-kernel - Re: [RFC 0/8] Aufs2 documents

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

Message-ID: <11466.1235808252@jrobl>
Date:	Sat, 28 Feb 2009 17:04:12 +0900
From:	hooanon05@...oo.co.jp
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/8] Aufs2 documents 

"David P. Quigley":
> I mean that in the event that an xattr can't be copied up to the next
> read-write branch the copyup should fail. Otherwise you get the
	:::
> I can see an "I know better" mount option being useful for this. I
> understand what you're trying to do now.

Then I don't see difference between what you wrote and my idea.
I think I should assert first that aufs doesn't support xattr currently.

> The point I was trying to make with iso9660_t is that since the xattr
> interface is what is used for security labels regardless of whether the
> underlying file system actually supports xattrs there are other places
> that the security label may come from. Since an iso9660 file system does
> not support extended attributes SELinux has a fixed type for all content
> on that file system. When someone asks for security.selinux on an
> iso9660 file system it goes to the inode, takes the security context in
> there, and converts it into the string you see even though there is no
> real xattr support.

For example, on a system which adopts selinux, if a user copies a file
manually from iso9660 (or other fs which doesn't support xattr) to a
xattr-supported fs, then he will not meet a security risk.
Is it correct?

And in the reverse case, copying a file manually from an xattr-supported
fs to non-supported fs may drop security info. Since this is manual
operation, user should know the risk. Right?
Here what will be security.selinux for the copied file?
Will it be set to the default value which is defined by a global policy
or something?
If it is true, then what will happen when the global policy has the
highest security level? User will not meet a security risk either?
Or such policy is useless in real world because of too low usability?

While these questions may sound silly, I just want to know how the
protection will be damaged in detail. Still I don't know much about
selinux.
I understand the case you want to clarify which aufs copies file
internally instead of manually. But will you tell me the comparision
between internal file copy and manual copy?

Anyway I guess aufs should support xattr in the future. I just want to
fix its priority, particulary it has to be implemented before
review/merge.

J. R. Okajima
--
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/