On Wed, Jun 21, 2006 at 04:34:59PM -0600, Mark Shellenbaum wrote:
Can you give us an example of a 'file' the ssh-agent wishes to open and
what the permission are on the file and also what privileges the
ssh-agent has, and what the expected results are.
ssh-agent(1) should need to open no
Mark Shellenbaum wrote:
Can you give us an example of a 'file' the ssh-agent wishes to open and
what the permission are on the file and also what privileges the
ssh-agent has, and what the expected results are.
The whole point is that ssh-agent should NEVER be opening any files that
the user
On Thu, Jun 22, 2006 at 01:01:38AM +0200, [EMAIL PROTECTED] wrote:
I'm not sure if I like the name, then; nor the emphasis on the
euid/egid (as those terms are not commonly used in the kernel;
there's a reason why the effective uid was cr-cr_uid and not cr_euid.
In other words, what your
Nachricht-
Von: Nicolas Williams [mailto:[EMAIL PROTECTED]
Gesendet: Do 22.06.2006 04:36
An: Nicolai Johannes
Cc: [EMAIL PROTECTED]; zfs-discuss@opensolaris.org
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
On Thu, Jun 22, 2006
An: Nicolas Williams
Cc: Nicolai Johannes; [EMAIL PROTECTED]; zfs-discuss@opensolaris.org; Mark
Shellenbaum
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
On Thu, Jun 22, 2006 at 01:01:38AM +0200, [EMAIL PROTECTED] wrote:
I'm not sure
Concerning the reopen problem of files created in world writable dire=
ctories:
One may use the following algorithm:
First compute the permissions of the newly created file.
For every permission granted to the user or group, check whether the =
corresponding identity-privilege is set. If not,
Yes, world readable/writable files can still be accessed by dropping =
the new privileges. One reason are library calls that need to read so=
me public files (like things in /etc). The need to manipulate or remo=
ve world writable files is harder to justify, on the other hand, worl=
d writable
On Thu, Jun 22, 2006 at 11:55:05AM +0200, [EMAIL PROTECTED] wrote:
Yes. It's kind of enticing.
I'm not entirely clear as to the problem which it solves; I think
I'd much rather have a user which cannot modify anything.
The canonical example would be, I think, ssh-agent(1), although I'm
not
On Thursday 22 June 2006 16:55, you wrote:
Yes, world readable/writable files can still be accessed by dropping =
the new privileges. One reason are library calls that need to read so=
me public files (like things in /etc). The need to manipulate or remo=
ve world writable files is harder to
Another concern would be: what UID owns files created by such processes?
I don't think it could be anything other than the current euid;
otherwise it is too easy to create files under a different uid.
For non-basic privs we can always do things with the client's root
credential and, when
On Thursday 22 June 2006 17:15, you wrote:
On Thu, Jun 22, 2006 at 11:55:05AM +0200, [EMAIL PROTECTED] wrote:
Yes. It's kind of enticing.
I'm not entirely clear as to the problem which it solves; I think
I'd much rather have a user which cannot modify anything.
The canonical example
On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
Concerning the reopen problem of files created in world writable
directories: One may use the following algorithm: First compute the
permissions of the newly created file. For every permission granted
to the user or group,
On Thu, 2006-06-22 at 10:55, [EMAIL PROTECTED] wrote:
To me, a PRIV_OBJECT_MODIFY which is required for any file modifying
operation would seem to be more useful as often a read-only user is
a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
in case you want to prevent any
On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote:
On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
Concerning the reopen problem of files created in world writable
directories: One may use the following algorithm: First compute the
permissions of the newly
On Thu, Jun 22, 2006 at 11:06:48AM -0700, Jonathan Adams wrote:
On Thu, Jun 22, 2006 at 12:49:03PM -0500, Nicolas Williams wrote:
On Thu, Jun 22, 2006 at 12:54:32PM +0200, Nicolai Johannes wrote:
Concerning the reopen problem of files created in world writable
directories: One may use the
On Thu, 2006-06-22 at 10:55, [EMAIL PROTECTED] wrote:
To me, a PRIV_OBJECT_MODIFY which is required for any file modifying
operation would seem to be more useful as often a read-only user is
a worthwhile thing to have; perhaps mirrored with a PRIV_OBJECT_ACCESS
in case you want to prevent any
for new basic privileges related
with filesystem access checks
Thinking about PID re-use, yes, but I'm not trying to design the
specific details -- I think a set of items to cache that provides strong
security guarantees can be found. The interface would remain
unpredictable in other ways
] Proposal for new basic privileges related with
filesystem access checks
Nicolai Johannes wrote:
Thank you for your hints.
I already investigated the zfs/ufs/tmpfs code when I wrote my proposal.
When I wrote check if set, I mean doing this with new secpolicy_vnode_*
functions. The check
-discuss@opensolaris.org
Betreff: Re: AW: [zfs-discuss] Proposal for new basic privileges related with
filesystem access checks
Nicolai Johannes wrote:
Thank you for your hints.
I already investigated the zfs/ufs/tmpfs code when I wrote my proposal.
When I wrote check if set, I mean doing
Processes like ssh-agent that do not need their identiity may drop =
them. An exploit too these processes may not exploit the fact, that t=
he euid/groups of the process allow some file operations that are den=
ied to everyone. Only files that are globally readable/writable/execu=
table may still
On Thu, Jun 22, 2006 at 01:01:38AM +0200, [EMAIL PROTECTED] wrote:
I'm not sure if I like the name, then; nor the emphasis on the
euid/egid (as those terms are not commonly used in the kernel;
there's a reason why the effective uid was cr-cr_uid and not cr_euid.
In other words, what your are
On Thu, Jun 22, 2006 at 02:45:50AM +0200, Nicolai Johannes wrote:
Spo as I have understood you, explaining the new privileges with the
term anonymous user would be better? I actually thought about that
idea, but there is a subtle difference:
Hmmm, no I have no good name for it.
Concerning
22 matches
Mail list logo
