On 29.10.2009 0:27, Pavel Machek wrote:
That race is easily fixed.
No, you're not right.
After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file with permissions 0644
User2 opens file for read access on
On 27.10.2009 14:04, Vincent Zweije wrote:
On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to
On 26.10.2009 23:05, Isara Beaumont wrote:
Dan Yefimov said:
I do not think mounting /proc should change access control semantics.
It didn't in fact change anything. If the guest created hardlink to that file in
a unrestricted location, what would you say? Procfs is in that respect just
On 24.10.2009 2:05, Pavel Machek wrote:
On Sat 2009-10-24 01:12:51, Dan Yefimov wrote:
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please
On 24.10.2009 1:56, Pavel Machek wrote:
Now... go back to my original email:
%pa...@toy:/tmp/my_priv$ chmod 700 .
%# relax file permissions, directory is private, so this is safe
%# check link count on unwritable_file. We would not want someone
%# to have a hard link to work around our
On 24.10.2009 2:39, Pavel Machek wrote:
Original owner did chmod 666... after making sure traditional unix
permissions protect the file. Please look at original mail; it was
subtle but I believe I got it right, and file would not be writable
with /proc unmounted.
I remember the original mail
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
act
On 24.10.2009 10:47, Anton Ivanov wrote:
Following your logic we should all abandon directory permissions and
stick to file-only ones. Hmm... Dunno, probably the blood level in my
coffee subsystem is too high this morning, but I do not quite relish
that idea.
I didn't affirm that. I only told,
On 24.10.2009 20:59, Anton Ivanov wrote:
Not to tell about
that /proc/PID/fd/ contains only symbolic links, not files, so I can't
understand, how the original reporter managed to gain access to the file in the
restricted directory using that symlink.
The perms are definitely broken and without
On 24.10.2009 22:05, Anton Ivanov wrote:
It works on Debian 2.6.26 out of the box. It is not an obscure patched
kernel case I am afraid.
If you redir an FD to a file using thus redir-ed FD in /proc allows you
to bypass directory permissions for where the file is located.
Thankfully, file
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
act as hardlinks. Could that be fixed somehow? (I did look at the
kernel fs/proc/base.c but did not
On 25.10.2009 2:40, p...@maths.usyd.edu.au wrote:
Dear Pavel,
... that's exactly the problem.
I see, the /proc/*/fd/* objects seem confused: are they symlinks,
hardlinks, or open file descriptors? I guess should always act as
the latter, where access mode flags (O_RDONLY or O_RDWR) are set
On 26.10.2009 18:30, casper@sun.com wrote:
In Solaris, you don't have permission to access a file in /proc/pid/fd unless
you can control the processpid.
$ ls -l /proc/1/fd
/proc/1/fd: Permission denied
If you can controlpid, then clearly you have access the file anyway
simply by
On 26.10.2009 18:26, Pavel Machek wrote:
On Mon 2009-10-26 18:11:56, Dan Yefimov wrote:
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD
On 26.10.2009 18:58, Pavel Machek wrote:
guest certianly does not have permission to ptrace() pavel's
processes, so...
But guest has permissions to ptrace() his own processes. If we
remember your original report, he abuses input redirection of bash
run by himself. So again, there's no real
On 26.10.2009 18:14, nom...@nomail.com wrote:
I do not think mounting /proc should change access control semantics.
It didn't in fact change anything. If the guest created hardlink to that file in
a unrestricted location, what would you say?
Do your homework and test it. You can't create
On 23.10.2009 21:16, Pavel Machek wrote:
Hi!
This is forward from lkml, so no, I did not invent this
hole. Unfortunately, I do not think lkml sees this as a security hole,
so...
Jamie Lokier said:
a) the current permission model under /proc/PID/fd has a security
hole (which Jamie is
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an attacker?
No, that was the
On Fri, 17 Aug 2007, Glynn Clements wrote:
There definitely appears to be potential for DoS against system-wide
resources.
Only the potential. In most cases that potential will remain unimplemented
since there are only a few setuid binaries in the system, so the real DoS
attack may be either
On Thu, 16 Aug 2007, Glynn Clements wrote:
However, the bug in question allows sending signals which cannot be
blocked or ignored (SIGKILL, SIGSTOP). Moreover, the cause (PDEATHSIG)
cannot be disabled
Really? An what if we fork right after startup and perform operations as a
child?
On Fri, 17 Aug 2007, Glynn Clements wrote:
Really? An what if we fork right after startup and perform operations as a
child?
That would work, but might have undesirable consequences of its own.
In particular, it prevents a non-malicious caller from using PDEATHSIG
to send e.g.
On Fri, 17 Aug 2007, Nicolas Rachinsky wrote:
* Dan Yefimov [EMAIL PROTECTED] [2007-08-17 05:27 +0400]:
BTW, SIGKILL and SIGSTOP can be issued by an O_ASYNC file I/O also (look in
fcntl(2) at F_SETSIG section). If you use F_SETSIG for sending SIGKILL or
SIGSTOP, there's nothing
On Wed, 15 Aug 2007, Wojciech Purczynski wrote:
Sending a signal to privileged process is a privilege itself.
Sure. But once control was transferred to some other code that we have no
control over, we have no more control over when the signal is sent. We just
can't send that signal at
On Thu, 16 Aug 2007, Glynn Clements wrote:
The signal in question in the given situation is issued by PRIVILEGED
process,
no matter how.
And that's the bug,
The case we consider is of course a bug. But generally privileged process
sending a signal to another privileged process is of
On Tue, 14 Aug 2007, Wojciech Purczynski wrote:
Small correction - I forgot to add setuid(0) ;)
PARENT CHILD
fork()
prctl(PR_SET_PDEATHSIG)
On Wed, 15 Aug 2007, Glynn Clements wrote:
If setuid program just
trusts the environment in that it doesn't properly handle or block signals
whose default action is terminating the process and doesn't perform it's
actions in a fail-safe manner, it is certainly broken. Setuid program
On Wed, 15 Aug 2007, Wojciech Purczynski wrote:
This doesn't change anything in what I said previously. If the sender's
EUID or RUID equals to any of SUID or RUID of the victim or the sender
process is root, the sender can send any signal to the victim; if none
of those conditions are
On Wed, 15 Aug 2007, Wojciech Purczynski wrote:
The problem is that without suid binary execved from parent process you
can not send the signal. ;) With suid binary you can and that makes this
issue a privilege escalation vulnerability.
Could you please explain it to me where do you see
On Tue, 14 Aug 2007, Wojciech Purczynski wrote:
===[ ABSTRACT ]=
An unprivileged local user may send arbitrary signal to a child process
despite security restrictions.
===[ AFFECTED SOFTWARE
On Tue, 14 Aug 2007, Wojciech Purczynski wrote:
I'm not sure this is a real security issue. If some process has the same
effective UID as the given one, the former can always send any signal to
the latter. Thus the behaviour you described is IMHO normal.
It becomes a security issue
30 matches
Mail list logo
