On Fri, 22 Sep 2006 17:26:06 +0200, Nicolai Johannes
<[EMAIL PROTECTED]> wrote:
Hi Frank,
first of all, have you read my document under
http://myhpi.de/~nicolai/GSoC.pdf that describes the intentions and
ideas behind my changes as well as the concrete implementation?
Thanks Johannes, this is an excellent document and was filling in the gaps
I had when looking into the code. Would love to have seen in in the first
place ;-)
To
1) tdirenter has not to be changed because all relevant functions that
call this function (create/createlink/createsymlink) already contain the
necessary checks
This was not possible for ufs because it checks whether a file is
present in the tdirenter function and not in the
createlink/file/hardlink functions.
Sounds reasonable, x-checking this assured me this being the case.
So I'm set for now.
Probably more for Darren though:
However IMHO, me failing to recognize this in the first place
also highlights the problem I have with the whole approach at all
how this privilege support your code is based on does interact
with the file systems.
The privilege checking code seems to be scattered all over the file
systems code or evolves to being so, and your new code
does add even more levels of complexity into the underlaying
file system. taking ufs_link() as a prime example we get
a cascading permission check triage like this:
ufs_link()
- the new checks - secpolicy_vnode_nanon_create_hardlink(cr)/
secpolicy_basic_link(cr)
- call into ufs_direnter_lr()
ufs_direnter_lr()
- ufs_iaccess(tdp, IEXEC, cr)) + the new checks
if exists and DE_RENAME:
ufs_dirrename()
- ufs_iaccess(tdp, IWRITE, cr)) + the new checks
- ufs_sticky_remove_access(tdp, tip, cr) + new
checks
if not exist and DE_LINK, DE_SYMLINK or DE_RENAME:
- ufs_iaccess(tdp, IWRITE, cr)) + the new checks
The whole permission checking seems to get ugly these days more and more
as far as file system intenals is concerned.
I wonder - shouldnt there be ways for a cleaner and proper interface
to file systems, at the VOP level perhaps by extending VOP_ACCESS() ?
---
frankB
I think questions 2 to 4 are perfectly answered in the mentioned
document.
Thanks a lot for your review
Johannes
-----Original Message-----
From: Frank Batschulat (Home) [mailto:[EMAIL PROTECTED]
Sent: Fri 9/22/2006 4:46 PM
To: Nicolai Johannes; [email protected]
Cc: Darren J Moffat
Subject: Re: [ufs-discuss] Review for new basic privileges restricting
fileaccess requested
Johannes, this looks all fine to me so far.
Questions:
Johannes:
1) why is usr/src/uts/common/fs/tmpfs/tmp_dir.c:tdirenter()
not changed as well ?
Darren/Johannes:
2) What I'm missing for myself is a description of what particular
problem these changes to the priv. rules are to address thats
currently missing
3) what about ZFS/HSFS/PCFS ?
Darren:
4) I'm desperately missing a document for file system development
that describes the expectations/interactions/requirements for
file systems to support and implement priviliges properly.
thanks
---
frankB
On Wed, 09 Aug 2006 14:16:27 +0200, Johannes Nicolai
<[EMAIL PROTECTED]> wrote:
My mentor Darren Moffat suggested that I should ask for reviewers to
look
over the changes I made to introduce the new basic privileges
restricting
file access, introduced appropriate secpolicy_vnode_* functions in
policy.c
and ported UFS and TMPFS to use these functions.
My webrev is located at: http://myhpi.de/~nicolai/webrev/
To get an overview about the new basic privileges and its semantics, I
posted
the changes to priv_defs in this mail:
----------
basic privilege PRIV_FILE_NANON_READ
Without having set PRIV_FILE_NANON_READ, a process is only able
to perform read operations on globally readable files or
directories
because it can only act like an 'anonymous process' and cannot
benefit
from its euid, egid or group memberships.
Additional rights gained through PRIV_FILE_DAC_READ will not be
restricted if PRIV_FILE_NANON_READ is not set.
basic privilege PRIV_FILE_NANON_WRITE
Without having set PRIV_FILE_NANON_WRITE, a process is only able
to perform write operations on globally writable files or
directories
because it can only act like an 'anonymous process' and cannot
benefit
from its euid, egid or group memberships.
Additional rights gained through PRIV_FILE_DAC_WRITE will not be
restricted if PRIV_FILE_NANON_WRITE is not set.
basic privilege PRIV_FILE_NANON_EXECUTE
Without having set PRIV_FILE_NANON_EXECUTE, a process is only
able to perform execute operations on globally executable files
because it can only act like an 'anonymous process' and cannot benefit
from
its euid, egid or group memberships.
Additional rights gained through PRIV_FILE_DAC_EXECUTE will not
be
restricted if PRIV_FILE_NANON_EXECUTE is not set.
basic privilege PRIV_FILE_NANON_SEARCH
Without having set PRIV_FILE_NANON_SEARCH, a process is only
able to perform search operations on globally searchable
directories
because it can only act like an 'anonymous process' and cannot
benefit
from its euid, egid or associated groups.
Additional rights gained through PRIV_FILE_DAC_SEARCH will not be
restricted if PRIV_FILE_NANON_EXECUTE is not set.
basic privilege PRIV_FILE_NANON_OWNER
PRIV_FILE_NANON_OWNER allows a process to perform operations on
a file, directory or link that require ownership.
PRIV_FILE_OWNER may always substitute PRIV_FILE_NANON_OWNER.
Without having set at least one of both privileges, a process is
considered to be 'anonymous' and cannot benefit from its euid.
Affected operations are e. g. changing permission bits/acls,
changing
access and modification times, changing the gid of an owned file
or
directory when a process is member of this group, creating
hardlinks
to files owned by a UID equal to the process's effective UID, renaming
or
moving in a directory with the sticky bit, mounting a file system on a
mount
point owned by a UID equal to the process's effective UID and creating
of a
new file, directory or symbolic link.
To change permission bits/acls of an owned file
PRIV_FILE_NANON_READ
or PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE or
PRIV_FILE_DAC_WRITE
and PRIV_FILE_ANON_EXECUTE or PRIF_FILE_DAC_EXECUTE have to be set as
well.
To change permission bits/acls of an owned directory
PRIV_FILE_NANON_READ or PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE
or
PRIV_FILE_DAC_WRITE and PRIV_FILE_ANON_SEARCH or
PRIV_FILE_DAC_SEARCH
have to be set as well.
To change the gid of an owned file or directory when a process is
member of this group, at least one of PRIV_FILE_NANON_OWNER,
PRIV_FILE_OWNER, PRIV_FILE_CHOWN or PRIV_FILE_CHOWN_SELF has to
be
set. So privilege escalation due to permission changes are not
possible. If
a new file should be created PRIV_FILE_NANON_READ or
PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE or PRIV_FILE_DAC_WRITE
and
PRIV_FILE_ANON_EXECUTE or PRIF_FILE_DAC_EXECUTE have to be set as
well. If a directory should be created PRIV_FILE_NANON_READ or
PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE or PRIV_FILE_DAC_WRITE
and
PRIV_FILE_ANON_SEARCH or PRIF_FILE_DAC_SEARCH have to be set as
well.
So a process that was able to create a file or directory is
always
able to reopen or enter it later as long no privileges are removed from
its
effective set.
Additional rights gained through PRIV_FILE_OWNER will not be
restricted if PRIV_FILE_NANON_OWNER is not set.
basic privilege PRIV_FILE_GEN_READ
Without having set PRIV_FILE_GEN_READ, file or directory
operations that require read permissions will generally not be
granted
unless the PRIV_FILE_DAC_READ or PRIV_FILE_NANON_READ privilege
is
set. Additional rights gained through PRIV_FILE_DAC_READ or
PRIV_FILE_NANON_READ will not be restricted if PRIV_FILE_GEN_READ
is
not set.
basic privilege PRIV_FILE_GEN_WRITE
Without having set PRIV_FILE_GEN_WRITE, file or directory
operations that require write permissions will not be granted
unless the PRIV_FILE_DAC_WRITE or PRIV_FILE_NANON_WRITE privilege
is
set. Additional rights gained through PRIV_FILE_DAC_WRITE or
PRIV_FILE_NANON_WRITE will not be restricted if
PRIV_FILE_GEN_WRITE is
not set.
basic privilege PRIV_FILE_GEN_EXECUTE
Without having set PRIV_FILE_GEN_EXECUTE, file operations that
require
execute permissions will not be granted unless the
PRIV_FILE_DAC_EXECUTE or PRIV_FILE_NANON_EXECUTE privilege is set.
Additional rights gained through PRIV_FILE_DAC_EXECUTE or
PRIV_FILE_NANON_EXECUTE will not be restricted if PRIV_FILE_GEN_EXECUTE
is
not set.
basic privilege PRIV_FILE_GEN_SEARCH
Without having set PRIV_FILE_GEN_SEARCH, directory operations
that
require search permissions will not be granted unless the
PRIV_FILE_DAC_SEARCH or PRIV_FILE_NANON_SEARCH privilege is set.
Additional rights gained through PRIV_FILE_DAC_SEARCH or
PRIV_FILE_NANON_SEARCH will not be restricted if
PRIV_FILE_GEN_SEARCH
is not set.
----------
Thank you very much for any comment.
Johannes Nicolai
Open Solaris Google Summer of Code Student
_______________________________________________
ufs-discuss mailing list
[email protected]
_______________________________________________
ufs-discuss mailing list
[email protected]
