Looks like the change was in kernel 3.6:
/proc/sys/fs/protected_hardlinks
http://man7.org/linux/man-pages/man5/proc.5.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/565002
Title:
ldopen failing
Certainly Tavis's original attack is impossible, since you can't create
the hardlink:
$ ln /bin/ping /tmp/target
ln: failed to create hard link '/tmp/target' => '/bin/ping': Operation not
permitted
I don't know when the change was made to prevent hard-linking files the user
doesn't own, but
This is the commit that added the protection:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7
Ubuntu must turn it on by default.
The risk, without that kernel option turned on, is:
1. High priv (setuid etc) binary with
Douglas, thanks for your contrib The security issue was raised by
couples of guys in the ML back in 2010 about this one. But actually I
still think this might be more an "ICMP syndrom" now day. Say, ICMP had
a security issue back in the day, that was fixed but that people used to
quickfix by
I've managed to hack something together for a launcher:
https://github.com/paperclip/origin_experiment/tree/launcher
The main pain point is that you have to put the permission in both the
inheritable set, and the ambient set before it'll get passed to the new
process (that can use $ORIGIN).
--
Yes, this is deliberate behavior for execve with an AT_SECURE
transition. Environmental parameters such as the path to the executable
are not trustworthy in that case.
For safe use of Java with capabilities you will have to use a
restricted, custom launcher. I don't think such a thing exists
I've created a git repo to reproduce this issue without using ldopen:
https://github.com/paperclip/origin_experiment
However it now looks like this might be deliberate behaviour:
https://seclists.org/fulldisclosure/2010/Oct/257
Tavis says that expanding $ORIGIN allows attacks against SUID
I have something very similar on Ubuntu 18.04 where the RUNPATH in the
binary isn't working for normal linking.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/565002
Title:
ldopen failing with
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: glibc (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/565002
Title:
Sure it was LD open (aka dlopen) ...
Anybody has the skills to fix this one ?
--
ldopen failing with relative path when linux capability is set
https://bugs.launchpad.net/bugs/565002
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
I can confirm.
I need to give Firefox CAP_FOWNER to get it to stop failing to install
extensions when utime() fails on ntfs-3g -- and then I get libxul.so
... no such file or directory.
Also, do you mean dlopen, not ldopen?
--
ldopen failing with relative path when linux capability is set
11 matches
Mail list logo
