Next Page >>
Sincerely Your
Thus Debian kernel team should be blamed for that misbehaviour. Don't worry,
hardlinks behave just the same way, as you describe. Use authentic Linux
kernels, if you dislike that.
--
Sincerely Your, Dan.
it's inode. But in order to follow them you need privileges to read the process
memory, which hardly restricts the impact of this behavior. I don't think this
should be fixed, since /proc/<PID>/fd/ is mainly for debugging purposes.
--
Sincerely Your, Dan.
That can hardly be called a real security hole, since the behaviour described
above is expected, and is as it was conceived by design. If the file owner in
fact allows writing to it, why should Linux prevent that from happening?
--
Sincerely Your, Dan.
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 security hole here.
--
Sincerely Your, Dan.
files in it, so your pretensions are in fact illegitimate. Anyway, you're free
to consider that a security hole, but remember, that nobody is obliged to agree
with you in that or help you solving problems invented by yourself.
--
Sincerely Your, Dan.
>
Did you think of creating a hardlink to the file in an unrestricted location?
That is the like "security hole".
--
Sincerely Your, Dan.
No, that was the owner of 'unwritable_file', nobody else. What the 0666 file
mode means? It means, that everybody can write to the file, can't he? So why do
you believe that pretension legitimate?
--
Sincerely Your, Dan.
Given my citation above (I personally use Linux), that obscure test case looks
doubtful. If the original reporter uses some patched kernel, that doesn't matter
others.
--
Sincerely Your, Dan.
regular and special files, directories and even pipes file descriptors is in
fact possible and could be accomplished rather easily by checking the
corresponding inode (this is true at least for Linux).
--
Sincerely Your, Dan.
> violates this expectation.
>
Again, you're not right. See above.
--
Sincerely Your, Dan.
mode from the origin, you would be right, and procfs wouldn't allow opening
files in that directory too, but if you let others to traverse that directory
and open your believed to be secure files from the origin, it's your fault.
--
Sincerely Your, Dan.
trouble you, that guest's processes still retain open file descriptors and hence
access to files, that you believe should no longer be accessible to those
processes due to permissions you set?
--
Sincerely Your, Dan.
expressed their opinion. Thus continuing this discussion there can be considered
importunate. If you want them to change their opinion, demonstrate the real, not
artificially invented problem, that in fact demonstrates only file owner negligence.
--
Sincerely Your, Dan.
testing them. Remember the scenario from the original mail and try finding a
window, during which creating a hardlink would still work thus evading directory
permissions check.
--
Sincerely Your, Dan.
> creation is not prevented by the directory permissions.
>
Your (2) contradicts to (1) and confirms what I told, if you didn't notice that.
--
Sincerely Your, Dan.
Linux itself. In that case you are right, there is the privilege escalation
vulnerability, but vulnerability is in that particular binary. Linux itself
has nothing to do with that and should not be blamed at all.
--
Sincerely Your, Dan.
daemons, non-blocking i/o for files open before exec(), alarms, failed pageins,
etc. If the program (not necessarily setuid/setgid) can't properly handle those
situations, it is broken by design. Signals are not something we can trust.
--
Sincerely Your, Dan.
>
I got you. I just thought you want to reset everything successively including
sigmasks and open files :-) .
--
Sincerely Your, Dan.
And this IS generally impossible. Once spawned setuid root binary that will
send a signal while dying, you have no control over the moment the signal is
being sent at. The exploitation scenario for this bug is a bit artificial.
--
Sincerely Your, Dan.
inclined to consider signals a reliable and secure information source. They are
rather a subsidiary facility. Attached a patch that is meant to fix a bug in
question.
--
Sincerely Your, Dan.
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.
--
Sincerely Your, Dan.
There're no such publicly accessible file objects, as file descriptors, there're
only files (including special ones), directories and symlinks. But the above
words don't necessary relate to patched kernels like distributed by third parties.
--
Sincerely Your, Dan.
> simply by controlling it using a debugger.
>
In Linux the same access rules apply.
--
Sincerely Your, Dan.
it. Not to tell about your script is broken by design. With what object do you
'chmod 0666 unwritable_file', if that file is not designed for access by anybody
other than you? This is a rhetorical question.
--
Sincerely Your, Dan.
create a hardlink to the file in an unrestricted location before the directory
access becomes restricted. Again, procfs is just another, specific kind of
hardlinks.
--
Sincerely Your, Dan.
PDEATHSIG should be always reset on exec() like signal handlers are (I'm not
sure though if that is directly specified by any standard). Please correct me
if I'm wrong.
--
Sincerely Your, Dan.
>
But if it drops privileges (changes EUID back to RUID), it can't again send any
signal to setuid process.
--
Sincerely Your, Dan.
look at check_kill_permission() and group_send_sig_info() in kernel/signal.c
and reparent_thread() in kernel/exit.c in the kernel source tree (version
2.6.22).
--
Sincerely Your, Dan.
>
Specified with what? Do open files fall into this category? Does blocked signal
bitmap fall into it? What exactly are you going to reset?
--
Sincerely Your, Dan.
and 't' is the pointer to the task_struct of the root child. If one of those
checks succeeds then the entire check_kill_permission() succeeds. current->euid
is in our case 0, t->uid and t->suid are 0 too. So where is the problem?
--
Sincerely Your, Dan.
Next Page>>
|
