On Tue, Apr 29, 2003 at 02:42:57PM -0700, Robert White wrote:
> Opinions? Objections? Reasons I'm an idiot?
Working with Coda, I've thought about these issues many times. I believe
the user mapping is a many-many relationship, which is hard or even
impossible to represent with such a simple mapping. Also the mapping
would vary depending on which device/file hierarchy is inserted. For
Coda it even depends on which subtree within the filesystem you traverse
as those might access servers is different administrative organisations.
Not doing anything tricky and allowing nosuid,noexec,nodev,uid=XX,gid=XX
to apply to all filesystems (possibly within the VFS layer) is
probably a more reliable solution. Otherwise it just becomes too complex
to manage.
For Coda we're pretty much punting the uid mapping. It is used for
'presentation' purposes only as all security is based on the Coda token
and directory ACLs. We do not really use the unix owner and permission
bits. We also explicitly clear the SUID bit, and rely on a locally
installed copy of sudo or super (preferably with a modification to check
something like an SHA1 or MD5 checksum of the executable) to provide the
priviledge escalation. This way running setuid applications becomes a
local policy.
For sandboxing purposes, perhaps you could think in the direction of
mounting the device in an UML environment, or it's own namespace.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:33 EST