| View previous topic :: View next topic |
| Author |
Message |
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
 Posted: Wed Dec 04, 2019 10:44 am Post subject: A method of installing Gentoo. An ongoing project. |
 |
|
Hi all,
I wish to share some findings I've made to set up Gentoo in kind of more reliable way.
There is actually nothing new. All parts are known for many years.
A Problem:
Gentoo is source based distro with all implication it brings. Gentoo as most distros out there
is using dynamic linking, which makes system vulnerable to damaging or intentional/unintentional
remove of the certain .so files. I am personally a strong believer, that static linking is the better
way to go, but it seems to be not really possible with last GLIBC versions. To mitigate the problem
many big packages like browsers etc embed the standard libs and make them local for a given app.
Others use Docker or AppImage. The purpose is always the same - to isolate the critical app from
the changes which are coming from the system change/upgrade/downgrade. At the same time
because of safety reason or what ever else, some apps are quite critical to the version of GLIBC available
on the system (somefunction@GLIBC_2.29) and not only that one. That is why there is no easy
option to downgrade GLIBC, although it's not a physical=real problem, but convention=agreement
problem. There is a back compatibility for GLIBC, but no back compatibility for apps using GLIBC.
I.e. one can run an app made for older GLIBC or a newer GLIBC, but not vice versa. Although they both
might be identical in respect of used functions.
Binary distros are better here, because everything is aligned, although an app from newer version
might not run on the older version. One has to perform total upgrade to run some new apps, which
aren't available on older versions.
On Gentoo if libs breakage affects the toolchain, there is no way to repair the system on its own.
An additional surprise is, that even if a binary versions of the well working package is available
one can't run: emerge --usepkgonly @world, because premerge check will check ability of toolchain
to compile something, which is not required in that case. The check itself prevents you from repairing the system!
The solution is to emerge gcc, binutils and glibc separately before upgrading/downgrading the whole system.
The main question remains - where to get those binary packages, where everything is broken?
A Solution:
There are 2 ways out. One could have 2 root FS on one system or 2 root FS on separate systems.
It's nice to use a more powerful server to build binary packages and perform only a binary update
on a laptop, but it's not always available. Running 2 root FS on the same system might take more
disk space, than one would be ready to give away.
There is an easier alternative. One creates a folder within a root FS something like
| Code: | # mkdir /amd64-linux-gnu
|
and put there a stage3 tarball from the network. Expands it according to the manual
and performs a classic installation in chroot like in the manual. The only difference to speed
up the process one could copy own setting from the root FS:
| Code: | cp -r /etc/portage /amd64-linux-gnu/etc/
cp -r /var/lib/portage/world /amd64-linux-gnu/var/lib/portage/
|
N.B. I would add more later on if I have forgotten something now.
Then usual
| Code: | emerge --sync
emerge -emptytree --buildpkg @world
|
May be with some modifications like what you usually use for a clean world rebuild. I do use "-atv" options for example,
but it's not required.
Then from the main system you create the symlinks:
| Code: | ln -s /amd64-linux-gnu/var/cache/binpkgs /var/cache/binpkgs
ln -s /amd64-linux-gnu/var/cache/distfiles /var/cache/distfiles
ln -s /amd64-linux-gnu/var/db/repos /var/db/repos
|
Assumed, the standard location of above mentioned locations.
Again may be something is missed. Need to check.
Now you can perform a fully binary merge to your working root FS.
It's important, that you don't touch any config file within you chroot FS,
besides /etc/portage. Perform any modification on a working root FS only.
By now you would have 2 copies of hopefully working systems, which would
occupy 2x space on disk, which is expected.
Now the last and most interesting part. Emerge rmlint on your system and do:
| Code: | today=$(date +%Y%m%d%H%M%S)
host=$(hostname)
rmlint --types="minimal,ns" -p -g --no-crossdev --hidden --keep-hardlinked --rank-by=dlma -c sh:handler=hardlink,symlink -o sh:${today}_${host}_dups.sh /
rm rmlint.json |
It will create a sh script which will perform a hardlinking to all copies of your files located
in root FS and chroot (on the same FS!) The used space goes down back to 1.0X.
Additionally before doing that you might:
| Code: | emerge --tree --depclean --with-bdeps=n
|
on chroot and if you didn't that before rmlint then on both root FS and chroot.
It will further reduce occupied space on disk.
Next time if you do upgrade --usepkg flag in chroot.
to prevent each time building the dependencies.
The upgrade sequence looks like that:
| Code: | chroot /amd64-linux-gnu
emerge --usepkg --binpkgs --update @world
|
Check if everyhing is OK. Leave the chroot and perform:
| Code: | emerge --usepkgonly --upate @world
emerge --tree --depclean --with-bdeps=n
rmlint --types="minimal,ns" -p -g --no-crossdev --hidden --keep-hardlinked --rank-by=dlma -c sh:handler=hardlink,symlink -o sh:${today}_${host}_dups.sh /
|
Benefits:
The advantage of such a configuration is, that you can break only a single root in a time and be able to repair
things from the other one. The total space consumption multiplier is close to 1x like for a single installation.
You always have default configs readily available if something went wrong with a working copy.
Even if your system is broken to no use status you can always boot from USB and chroot into
still available and working chroot environment.
From now on you can upgrade/downgrade what ever you like in what ever order or direction.
While doing some risky experiments you may buildpkg without installation and install them in chroot
while testing if those are working in combination with rest of a system.
Next steps:
You may also get 2 or 3 chrooted systems and combine you fully binary installation with them.
For example I wish to try a fully static musl based chroot and update partially (@system only) my working system
with that. Or one can do a transition from installation with one libc to another one...
Recently I've got sta.li distro on chroot and was shocked how much smaller some binary components are.
I'd like rebuild sta.li on gentoo at least core components.
Cheers!
_________________
Lefsha |
|
| Back to top |
|
 |
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Fri Dec 06, 2019 12:16 pm Post subject: |
|
|
I have found an issue due to the hardlinking:
| Code: | | suid/sgid file(s) with suspicious hardlink(s): |
Question: How to disable/mitigate the installation abort?
hardlink are not suspicious, but were made on purpose.
preinstall didn't want to check deeper, that everything is safe
and stops here.
P.S. I am missing Old School Gentoo a lot...
Would be great if all those "modern" features could be disabled.
P.P.S. Wondering, people blame systemd for something and do exactly the same.
_________________
Lefsha |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Fri Dec 06, 2019 10:08 pm Post subject: |
|
|
Well, things at Gentoo are worse, than I have expected. Still Gentoo is at great Luck.
Nowadays almost all other distros went even more crazy.
Although, I have almost left Gentoo again towards Paludis and Exherbo, which I discovered
immediately after looking at home page of Paludis...
The goal was to find a ebuild management system which is not that crazy,
without all these checks for nothing.
Frankly, I didn't try Paludis in real life. When I saw Exherbo is using systemd by default
it was clear there can't be anything good about Paludis. One can change a program, but
one can't change the way people are thinking.
More over paludis claims beeing independent from Python, which I would love to have,
but instead it depends on asciidoc (why?) and that beast depends on python...
If non bloated dependency looks that way I have no words to say.
I was left with only one option - modify portage to make it working for me.
I_DO_KNOW_WHAT_I_AM_DOING_ONCE_AND_FOREVER_GOD_SAVE_ME option doesn't help anymore.
Luckily I found, that I just need to comment few lines at vartree.py and things are working back again.
Now I am almost happy, that portage is written in Python.
It looks like writing a crap software in Python could be beneficial for end user.
Because most (90% or so) software is crap I am starting to understand why people love python...
Now I an uncertain, whether I need to make my copy of portage (forking it) or is just enough to
prevent file overwrite by "chattr +i". For now I use the simplest option and if there will be more
issues I will fork it.
If any one reading that I would be glad if some one point me to the oldest portage version, which can be used,
but without Master_of_the_ring behavior or a fork to save me from work.
_________________
Lefsha |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3150
|
| Posted: Sun Dec 08, 2019 4:25 pm Post subject: |
|
|
| Quote: | Now I an uncertain, whether I need to make my copy of portage (forking it) or is just enough to
prevent file overwrite by "chattr +i". For now I use the simplest option and if there will be more
issues I will fork it. |
Create a patch.
Dump it into /etc/portage/patches/<portage_cathegory>/<portage package name>/<your_custom_name>.patch
You can create a patch with diff -u /path/to/extracted/source/ /path/to/modified/source/
You're welcome, go for it! |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21703
|
| Posted: Sun Dec 08, 2019 5:26 pm Post subject: |
|
|
lefsha: do you know why unexpected hard links are suspicious in the general case? If no, then you don't actually know what you're doing here.  These checks were added for a reason, and while the error message could be better, they are not something to be bypassed lightly. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Dec 08, 2019 8:50 pm Post subject: |
|
|
| Hu, can you enlighten us? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21703
|
| Posted: Sun Dec 08, 2019 10:17 pm Post subject: |
|
|
| I can offer one reason that Portage should generate this warning. I don't know if it is the reason that motivated the inclusion of the warning. Before I explain, I'd like to see if lefsha knows, since he seems to know better than any of us how this all should work. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Dec 08, 2019 11:37 pm Post subject: |
|
|
| Hu wrote: | | lefsha: do you know why unexpected hard links are suspicious in the general case? If no, then you don't actually know what you're doing here. These checks were added for a reason, and while the error message could be better, they are not something to be bypassed lightly. |
That was what I wanted explained.
No, I do not know why hardlinks are dangerous. |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Tue Dec 10, 2019 10:52 pm Post subject: |
|
|
| szatox wrote: | | Create a patch. |
Great advice! Thanks a lot!
_________________
Lefsha |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Tue Dec 10, 2019 11:07 pm Post subject: |
|
|
| Hu wrote: | | do you know why unexpected hard links are suspicious in the general case? |
After 20+ years with Linux and 2+ before that with FreeBSD what is your guess?
It is very similar issue like one I have reported. Gentoo either takes its users as adults or
like kids. The playground for kids is occupied by Ubuntu. Make the conclusion yourself...
It's fine to warn a user, but it's terribly bad to prevent user from doing something the developer
would never come to. Keep the door open and people would stay. Shut the doors and every one
will leave. That rule is valid for last 1000+ years at least. Why it is soo difficult to get it?
Nobody can guess what is on my or anyone's else mind. Not every situation can be foreseen.
At least you know by now, that there is some one who disagree on some portage features.
I will patch it for myself and I don't ask anyone to change it for everyone.
Still I do appreciate your active participation in the forum. And last but not least
I do like people who disagree with me! That is most useful in life. Thank you a lot!
P.S. I have noted, that Neddy is running his own special personal Gentoo. Was it not the topic
of interest for developers to understand why he is doing so? May be the following all kind of modern
trends is not really the main goal for such a distro like Gentoo? For example I am really missing
a server oriented distro or cluster oriented one. The area, where Kubuntu is the last option after Windows...
_________________
Lefsha |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Tue Dec 10, 2019 11:47 pm Post subject: |
|
|
| Hu wrote: | | I can offer one reason that Portage should generate this warning. I don't know if it is the reason that motivated the inclusion of the warning. Before I explain, I'd like to see if lefsha knows, since he seems to know better than any of us how this all should work. |
I am a lazy boy. Here is the link https://wiki.gentoo.org/wiki/Security_Handbook/File_permissions
Unfortunately there is some nonsense written there in regard to SUID/SGUID files, so please don't proceed with
actions recommended there. You have been warned! No kidding.
But OK. Let's read the story kids...
The idea of hard links with combination of SUID is quite simple actually.
A file has it's inode. The path name like /bin/sudo is just a pointer. It can be 1 pointer or multiple pointers.
If there is 2+ pointers to the same inode it calls a hardlinking. Actually it's not.(*) Those are just 1+ pointers to the
same area on disk. Deleting an inode and deleting a pointer are 2 different operations.
It's like multiple people in the room. The last one who is leaving the room turning of the light.
No light - no inode - no file - no fun.
A limitation. Hard-linking exists only within the same file system. That is why the old school guys put /, /usr, /var and /home
on different file systems. Because our new Messiah known by the acronym LP has arrived it is not possible, not
desired not cool anymore. Everything what's new is always better and people from the past are stupid idiots.
N.B. Anyone who has noted above a gentle touch of sarcasm could keep it.
Now if some one will somehow create a hardlink to /bin/sudo and call it /var/tmp/apple_pie, then he/she could run it
as nobody and rise his permissions to the root level.
As we can see the modern Gentoo instead of following old school solution is listening to LP. And simply blaming anyone
who creates the hard links of SUID files wherever they are located. Portage actually doesn't care about the location and permissions
of that file. It just counts the number of hardlinks to SUIDed inode file. If N>1, then it's yelling.
The most funny thing in the story that the reaction is too late and not at the right moment if thinking really well.
The system IS already broken according to portage. The new update WILL repair the system by breaking the hard links apart within the corresponding package. And exactly this IS forbidden. The user should better stay with a risky configuration instead of repaired one... What a help...
How do you like it (Elon Mask) Mr. Hu?
P.S. * "Actually it's not". - There is no difference between each pointer to the data saved on disk. All of them are equivalent.
The first one is also kind of hardlink or none of them are the hard links. It is not like with softlinking, where only one pointer is real.
To me pointer is the better name.
_________________
Lefsha |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Wed Dec 11, 2019 12:47 am Post subject: |
|
|
Dear szatox!
Thank you sooo much!!! You've made my day!
It works. Here the link https://wiki.gentoo.org/wiki//etc/portage/patches how to deal
with patches.
That is really powerful feature I didn't know about!
Now I can modify any package including ebuilds... Boah...
That is really powerful feature. Love it!
P.S. Am I the only one who is patching the portage? Are there other patches?
_________________
Lefsha |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21703
|
| Posted: Wed Dec 11, 2019 2:12 am Post subject: |
|
|
| lefsha wrote: | | After 20+ years with Linux and 2+ before that with FreeBSD what is your guess? |
Based on your attitude to date, I wouldn't have thought you have been in the community nearly that long.
Interesting. You linked to a page that explains the problem, then proceeded to misunderstand it completely (or perhaps simply recap it incorrectly). | lefsha wrote: | Now if some one will somehow create a hardlink to /bin/sudo and call it /var/tmp/apple_pie, then he/she could run it
as nobody and rise his permissions to the root level. |
True, but this is not by itself dangerous, because it is still the code that was installed as /bin/sudo, so it still has all the limitations that sudo imposes. The problem, as described in the linked document, is that over time, vulnerabilities may be found. A responsible administrator will replace the vulnerable version with a fixed one as soon as possible. However, if a user has made a hard link to the vulnerable version, then when Portage updates the package, not all copies of the vulnerable suid program will be removed from the system. The user can then run the old vulnerable suid version and apply a new exploit to it. The user can speculatively hard link these files, in the hope that one day a vulnerability would be found, so the user can easily win the race by creating the links as soon as a version is installed, months or years before anyone knows about an exploit for it. | lefsha wrote: | | As we can see the modern Gentoo instead of following old school solution is listening to LP. |
This has nothing to do with Lennart or systemd. Novice users have created combined filesystems since well before systemd existed, and even users who know the risks will sometimes create a combined filesystem because of perceived advantages relative to those risks.
| lefsha wrote: | | Portage actually doesn't care about the location and permissions of that file. |
Permissions are part of the inode. It is not possible to have multiple links to a file and have different links have different permissions. All the links point to the inode, and the inode has exactly one set of permissions. | lefsha wrote: | | It just counts the number of hardlinks to SUIDed inode file. If N>1, then it's yelling. |
Not exactly. It warns if there count of hard links is not consistent with the files known to be owned by the package. | lefsha wrote: | The most funny thing in the story that the reaction is too late and not at the right moment if thinking really well.
The system IS already broken according to portage. The new update WILL repair the system by breaking the hard links apart within the corresponding package. And exactly this IS forbidden. The user should better stay with a risky configuration instead of repaired one... What a help... |
This is also not exactly correct. Yes, the system is already broken, but this is the first opportunity Portage has to notice the problem. The system was fine when Portage first installed the package that owns the suid file. At some unspecified time afterward, someone created a presumably unauthorized hard link. Portage has no ability to detect the link appearing when it first happened, and even if it did, the link is not a security problem at that point, because the attacker could just run the original copy of the file. The hard link becomes a (potential) security problem when the administrator removes all known copies of the (potentially vulnerable) suid program, and then believes the system is now "safe." Unknown to the administrator, this extra hard link has preserved a potentially vulnerable copy, so the system isn't actually safe. Portage is trying to warn the user "You think you secured your system, but you're wrong. You need to find and eliminate this extra link." The message could be more pointed, but at least it does tell the user to go read the Gentoo Security Handbook.
Interestingly, while examining the Portage code so I could write this post, I noticed this special case: | Code: | if not stat.S_ISLNK(lstatobj.st_mode):
# Remove permissions to ensure that any hardlinks to
# suid/sgid files are rendered harmless.
os.chmod(file_name, 0)
os.unlink(file_name) |
I haven't looked into why the message about suspicious links is still present if Portage also renders the stale links harmless. Perhaps it is present to advise the administrator that someone tried something odd, and the administrator should investigate. Perhaps it is a remnant from before Portage actively disabled these links. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Dec 11, 2019 2:38 am Post subject: |
|
|
| lefsha wrote: | Although, I have almost left Gentoo again towards Paludis and Exherbo, which I discovered
immediately after looking at home page of Paludis... |
So you're ready to discard one distro over nothing but the promises on another's homepage (that hasn't materially changed in 10 years)…
| Quote: | The goal was to find a ebuild management system which is not that crazy,
without all these checks for nothing. |
…while not even bothering to learn the history or current state of paludis? Celebrating a lack of QA and strictures while rushing head first into *Exherbo*? You're in for a rude awakening.
| Quote: | Frankly, I didn't try Paludis in real life. When I saw Exherbo is using systemd by default
it was clear there can't be anything good about Paludis. |
or you could just stay asleep.
| Quote: | | One can change a program, but one can't change the way people are thinking. |
Took the words right out of my mouth.
Good luck with that. You're never going to be happy with any Linux distro. |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Wed Dec 11, 2019 12:24 pm Post subject: |
|
|
| Hu wrote: | | Based on your attitude to date, I wouldn't have thought you have been in the community nearly that long. |
What is wrong with my attitude? I am asking questions. I do believe it's OK. I should not agree on everything what other people are doing.
Moreover I do have my arguments and those cannot be contradicted so far. If you don't like something - tell me what is wrong.
There is no offense from my side. But yes may be I think different.
| Hu wrote: | | The problem, as described in the linked document, is that over time, vulnerabilities may be found. A responsible administrator will replace the vulnerable version with a fixed one as soon as possible. |
Did you check the statistics? How many people still use old software? At how many places the software update not possible or not desired?
And again old doesn't means bad. New doesn't means good or not vulnerable. The example was given. Under unfluence of systemd people have changed the root layout and got problems they never had.
| Hu wrote: | | However, if a user has made a hard link to the vulnerable version, then when Portage updates the package, not all copies of the vulnerable suid program will be removed from the system. |
Well, that is purely portage issue caused by design. Even mcedit is capable of not breaking hardlinks when saving a modified file.
Surely also portage is capable of doing that. So it is by design and not a restriction. And that is totally fine with me. It's not like I see here a problem.
| Hu wrote: | | The user can then run the old vulnerable suid version and apply a new exploit to it. |
Frankly. There is no push to update any system. Linux won't stop working if not updated for longer than a week or so.
That kind of argument is just not valid. If not updated for a year or so a system could vulnerable without any hardlinks.
The root cause is not hardlinks! That is the point. Having not updated hardlinks won't make a system less safe.
One also need to think well, who and why would create a hardlink to a critical file? - If everything is working well, why would
any one create a hardlink to a file he has an access anyway? What is the point in that?
Creating hardlinks could be only validated if one cannot access the original file in the original path. And that should be a safety
issue with hardlinks. Not because of update. I.e. normally I can't access that file, but I've got that opportunity over the hardlink.
Thus I could rise my rights in some cases.
| Hu wrote: | | The user can speculatively hard link these files, in the hope that one day a vulnerability would be found |
Not that fast. The user need... a permission to create a hard link. Not any file can be hardlinked by any user.
https://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1
| Quote: | On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given hardlink (i.e. a root process follows a hardlink created by another user). Additionally, an issue exists where users can "pin" a potentially vulnerable setuid/setgid file so that an administrator will not actually upgrade a system fully.
The solution is to permit hardlinks to only be created when the user is already the existing file's owner, or if they already have read/write access to the existing file.
|
Who ever pushed a user to have write permission to /tmp or any other places in the root fs?
A user can be fully satisfied with using ~/tmp as temp dir.
It's like making a bridge out of glass and then put a lable - please don't walk on it or it will crash... A nonsense.
While using portage and installing some software we are using root user. That kind of user may create any hardlinks he wish to.
But that should or must be considered as OK. The root should know what and why he is doing. Linux doesn't prevent me
from running "rm -f /" in the first place, which can break my system much faster, than any imaginary exploit.
Why it is not forbidden till now?
One need to take all these safety measures with cool head and look for a root cause and not symptoms.
Figthing against symptoms won't make linux more safe, but rather more difficult to use.
Rheum is a symptom and not a root cause. Unfortunately we always see the ads against it on TV. The same here.
| Hu wrote: | | This has nothing to do with Lennart or systemd |
Oh, really? https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
I do still remember how to google. Please, if you arguing with me take it serious. I repeat - I like if people have a different
opinion and I am always ready to prove myself being wrong.
Please, answer a simple question. How a system can be vulnerable because of hardlinks IF system and user side are separated from
each other? If no user can make a hardlink to any system file. I do believe you still remeber what "s" in /sbin stands for.
I do believe, that you are aware, that /sbin and /usr/sbin are gone on all systems with systemd on board.
Not the case with Gentoo, though!
It is much better to create a design, where you cannot break the rules instead of blaming user for doing something which is unsafe.
Linux, unfortunately is closing gap to Windows way too fast. 10-20 years ago Linux was safer, than it is now with all these bells and whistles
we've got now.
| Hu wrote: | | Novice users have created combined filesystems since well before systemd existed, and even users who know the risks will sometimes create a combined filesystem because of perceived advantages relative to those risks. |
The user (root) should be able to do what ever he wants to. A knife is also dangerous, but it's not the reason to forbid it from selling.
A system with help of admin/root should take care of non root users and only them. A distro like Gentoo here should provide the documentation
of what to do and what not. It is already done. There are tons of docus, besides the manual pages.
Still I can walk to a highway and get over-rolled by a track. And that is not the track problem neither a problem of who has built the road.
Nothing is absolutely safe.
Am I wrong?
| Hu wrote: | | Not exactly. It warns if there count of hard links is not consistent with the files known to be owned by the package. |
Well, agreed. Things like busybox use that a lot. Although I am not sure what is better here - a softlink or a hardlink. But you've got my point.
| Hu wrote: | | Portage has no ability to detect the link appearing when it first happened, and even if it did, the link is not a security problem at that point |
Look. IF it is unsafe to create a hardlink to the particular file, then it should be forbidden! It's quite easy to achieve that.
Now we are assuming only the root can do that. If that is the attacker, then it is just way too late to react, because he owns the system.
There is absolutely no reason for him to use some vulnerability whatsoever to do something. If root is not an attacker, than we can assume
a hardlink has been created on purpose. Yes, we can warn about it, but that is it.
A different general approach to the problem: One should forbid something, which can be really forbidden! Portage is simply incapable
to forbid to root anything. No one can. In portage development I need to be very clear about that.
| Hu wrote: | | The hard link becomes a (potential) security problem when the administrator removes all known copies of the (potentially vulnerable) suid program, and then believes the system is now "safe." |
IMHO it is unrealistic scenario. I never walk through the file system and looking for SUID files or their hardlinks.
If any single user is capable to create a hardlink, then even I remove them as an admin, they will be created over and over again.
If it was done by the root, then it's his responsibility to track it existence. Why would root not know about it in the first place?
If root is worry about that, he can create a softlink which will track the original file update. It works exact the same way, but one don't
need to take care of it. Dangling links can be easily removed automatically.
You imagine a problem where none is existing.
| Hu wrote: | | ...it does tell the user to go read the Gentoo Security Handbook. |
... which is not correct as I have mentioned earlier. I followed the advises there and broke my system. Nice.
If the portage does installs 1000+ files with SUID, those should be kept that way. And if that is wrong it should
be repaired by the upstream and not by the admin. Blindly following the instructions is bad too.
Good that I had binary packages and could repair the system quite fast. Random update didn't helped and I had to reinstall everything.
I would suggest to remove those advises.
_________________
Lefsha |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Wed Dec 11, 2019 1:09 pm Post subject: |
|
|
| Ant P. wrote: | | So you're ready to discard one distro over nothing but the promises on another's homepage (that hasn't materially changed in 10 years)… |
You might not realized it yet, but I just came back from Arch... And yes I do discard the distros if I think it's required.
What is the problem with that?
Anyway before doing something I am reading a lot. Sometimes its not enough. One need to test it.
For example I am still testing Gentoo, cause my server works under Arch. Well, not real Arch, but Artix.
Now I feel it's not enough.
I have started server with FBSD, because I want ZFS and was uncertain of being able to run it under Linux.
By now I feel confident with ZFS and can run it under Linux. Moreover I feel OK to run it under Gentoo.
Although it is more fragile, than Arch for example. I have reported some issues.
| Ant P. wrote: | | …while not even bothering to learn the history or current state of paludis? Celebrating a lack of QA and strictures while rushing head first into *Exherbo*? You're in for a rude awakening. |
Hey hey not that fast. The only thing I really did was READING. Why do you blame me?
| Ant P. wrote: | | Good luck with that. You're never going to be happy with any Linux distro. |
I am not. They are more or less suitable for me. There is none which is best in everything.
Like in Windows the amount of available software is critical.
I like sta.li if it would be source based with USE flags and a lot of software.
_________________
Lefsha |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21703
|
| Posted: Thu Dec 12, 2019 3:43 am Post subject: |
|
|
| lefsha wrote: | | What is wrong with my attitude? I am asking questions. I do believe it's OK. I should not agree on everything what other people are doing. |
I'm not asking you to agree to everything, but you come off as unnecessarily confrontational. In particular, your earlier posts that I alluded to above give the impression that you think you know better than the people who wrote this software, yet you don't even seem to understand the problems they are trying to solve. | lefsha wrote: | | Moreover I do have my arguments and those cannot be contradicted so far. If you don't like something - tell me what is wrong. |
Haven't I done that several times already? | lefsha wrote: | | Hu wrote: | | The problem, as described in the linked document, is that over time, vulnerabilities may be found. A responsible administrator will replace the vulnerable version with a fixed one as soon as possible. |
Did you check the statistics? |
What statistics? | lefsha wrote: | | How many people still use old software? At how many places the software update not possible or not desired? |
How is this relevant? The problem is that if a vulnerable suid program is on the system, it can be exploited. Through link abuse, a malicious unprivileged user can retain a vulnerable suid program past the time when the administrator tried to replace it with a fixed version. The malicious user can, and if he is at all clever, will, create these links as soon as possible, likely before the vulnerability is known to anyone. The link then lingers, waiting for someone to find a viable exploit.
| lefsha wrote: | | And again old doesn't means bad. New doesn't means good or not vulnerable. |
In the context of suid programs, for which vulnerabilities are discovered and patches are issued, that is exactly what it means. Programs with known vulnerabilities are bad. Programs without known vulnerabilities are less bad. Responsible administrators will remove vulnerable programs or replace them with fixed versions as soon as practical.
We are not discussing the more general case where upstream makes unpopular decisions or introduces new bugs. We are discussing the very limited case that the administrator of the system has chosen to remove a file, a hard link has prevented the administrator's action from being fully effective, and the most likely explanation for the existence of the hard link is that someone is planning to behave in a way contrary to the administrator's intent. In that scenario, the package manager tries to notify the administrator that the file is not fully removed, and that this is probably something the administrator should investigate. | lefsha wrote: | | The example was given. Under unfluence of systemd people have changed the root layout and got problems they never had. |
Sure, systemd has made some bad decisions and caused problems. That is out of scope here. systemd does not have a monopoly on releasing exploitable privileged programs. Working from memory, I can't even cite an example of systemd having a suid program that was a security problem. Their memorable security problems have all been of the more embarrassing intentional variety, like having a parser that runs programs as root if it can't figure out what user to use. | lefsha wrote: | | Hu wrote: | | However, if a user has made a hard link to the vulnerable version, then when Portage updates the package, not all copies of the vulnerable suid program will be removed from the system. |
Well, that is purely portage issue caused by design. Even mcedit is capable of not breaking hardlinks when saving a modified file.
Surely also portage is capable of doing that. So it is by design and not a restriction. And that is totally fine with me. It's not like I see here a problem. |
I agree with your last sentence. You don't see the problem here, despite me trying several times to explain it. Until you understand the problem, you won't understand why Portage behaves as it does. | lefsha wrote: | | Hu wrote: | | The user can then run the old vulnerable suid version and apply a new exploit to it. |
Frankly. There is no push to update any system. Linux won't stop working if not updated for longer than a week or so. |
How is this relevant? | lefsha wrote: |
That kind of argument is just not valid. If not updated for a year or so a system could vulnerable without any hardlinks. |
True, but again irrelevant. The point of the discussion is that if the system is discovered to be vulnerable, and the administrator upgrades the affected packages to non-vulnerable versions, then that upgrade should have the effect the administrator expects. If a user has secret hard links preserving the old vulnerable copies, then the administrator does not get the expected result. | lefsha wrote: | | The root cause is not hardlinks! That is the point. Having not updated hardlinks won't make a system less safe. |
You are wrong here. If the administrator removes all the known vulnerable versions of the program, then the exploit becomes irrelevant. The hard links let an unprivileged user retain a known vulnerable version in direct violation of the administrator's intent. | lefsha wrote: | One also need to think well, who and why would create a hardlink to a critical file? - If everything is working well, why would
any one create a hardlink to a file he has an access anyway? What is the point in that? |
To retain the file for future use in an exploit, as explained above, repeatedly. | lefsha wrote: | Creating hardlinks could be only validated if one cannot access the original file in the original path. And that should be a safety
issue with hardlinks. Not because of update. I.e. normally I can't access that file, but I've got that opportunity over the hardlink.
Thus I could rise my rights in some cases. |
I don't understand what you are trying to say here. Under the traditional Linux security model, a user can hard link a file while having very little rights on the system. | lefsha wrote: | | Hu wrote: | | The user can speculatively hard link these files, in the hope that one day a vulnerability would be found |
Not that fast. The user need... a permission to create a hard link. Not any file can be hardlinked by any user. |
Historically, the required permissions to hard-link a file were very minimal.Yes, this commit helps. It's also semi-optional, and necessarily incomplete. It's a sysctl that can be disabled (though administrators hopefully know better than to do so). Even if we suppose that is never disabled, there remains the problem that it only blocks unprivileged users from creating the hard links. That is by far the most common avenue of exploitation, but it's not the only one. Suppose that an unprivileged user found a privileged process that could be tricked into creating hard links to arbitrary files. The user can exploit this process to create the dangerous hard link, and then we're right back to the point of the user waiting for someone to publish a usable vulnerability, and the administrator's upgrade attempt to be inadequate due to the unauthorized hard link. If you don't like that scenario, consider a close variant of the one you created in order to hit this error: an administrator willingly creates a hard link to a suid program, perhaps intending to delete it in short order or perhaps unaware of the risks, then forgets the whole thing. Time passes. A vulnerability is found, and the canonical installation is updated. This approved hard link persists a copy of the vulnerable version. Now, through no direct action of an unprivileged user, an exploitable situation exists and, without a warning from the package manager, the administrator does not even know there is a problem. To extend on this slightly, suppose this is a shared responsibility system where multiple users are entrusted with root. One of them makes the dangerous link, not intending to cause problems. A different one handles software updates, and so has no reason to know about the bad link.
| lefsha wrote: | | Who ever pushed a user to have write permission to /tmp or any other places in the root fs? |
This is the wrong question. The right question is "Are there systems where a suid file is installed on a filesystem where untrusted users can create hard links?" | lefsha wrote: | | A user can be fully satisfied with using ~/tmp as temp dir. |
Sure, or the administrator could put /tmp on a separate filesystem.
| lefsha wrote: | While using portage and installing some software we are using root user. That kind of user may create any hardlinks he wish to.
But that should or must be considered as OK. The root should know what and why he is doing. Linux doesn't prevent me
from running "rm -f /" in the first place, which can break my system much faster, than any imaginary exploit.
Why it is not forbidden till now? |
Mitigations are not always added as soon as we may wish. However, it is here now, and I am glad for it. | lefsha wrote: | One need to take all these safety measures with cool head and look for a root cause and not symptoms.
Figthing against symptoms won't make linux more safe, but rather more difficult to use. |
What do you think the root cause is? The ability to hard link a file that has the suid bit set?
How is this relevant? /usr is not normally writable to unprivileged users, so moving /usr into / is relevant only if you assume that the dangerous suid programs are in /usr. Some might be, but vulnerabilities in programs installed to /bin have happened too. | lefsha wrote: |
Please, if you arguing with me take it serious. |
I am taking it seriously. That is why I have spent a considerable amount of time trying to explain this to you, rather than ignoring your posts as I first considered doing. | lefsha wrote: | I repeat - I like if people have a different
opinion and I am always ready to prove myself being wrong. |
Ready and able, apparently. | lefsha wrote: | How a system can be vulnerable because of hardlinks IF system and user side are separated from
each other? If no user can make a hardlink to any system file. |
I outlined two scenarios above where a dangerous hard link could be created despite securing the system. More generally, you're assuming everyone will install their system in the most secure configuration. That's not a valid assumption. Some people will, through ignorance or conflicting requirements, create systems that are susceptible to these problems. When a mitigation is cheap, has minimal negative side effects, and is likely to help real users, it is worth considering for inclusion. | lefsha wrote: | I do believe you still remeber what "s" in /sbin stands for.
I do believe, that you are aware, that /sbin and /usr/sbin are gone on all systems with systemd on board. |
That's not relevant here, because hard links look at the filesystem level, not the directory level. Merging /bin into /sbin means nothing to the problem under discussion. Merging /bin into /usr/bin means nothing if /usr is part of /. As you reminded above, systemd strongly encourages making /usr part of /.
| lefsha wrote: | | Am I wrong? |
I don't understand your point here, so I can't judge its correctness.
| lefsha wrote: | Look. IF it is unsafe to create a hardlink to the particular file, then it should be forbidden! It's quite easy to achieve that.
Now we are assuming only the root can do that. If that is the attacker, then it is just way too late to react, because he owns the system.
There is absolutely no reason for him to use some vulnerability whatsoever to do something. If root is not an attacker, than we can assume
a hardlink has been created on purpose. Yes, we can warn about it, but that is it. |
You are making a common mistake here. You assume that an attacker either cannot do anything as root, or that he can do everything as root, but that he has no other level of access. In reality, there have been plenty of cases of a bug in a root privileged program where malicious input can trick it into doing some particular action as root, but where the attacker cannot run arbitrary code as root. For the case at hand, suppose a privileged process is given a user-chosen filename, a user-chosen directory name, and creates a hard link in the directory to the user-chosen file. Whether the process does this due to an exploit or just a strange design does not matter. The point is that the attacker can now link files that the kernel would not let him link directly, but he can't do anything else as root as a result of this process.
| lefsha wrote: |
| Hu wrote: | | The hard link becomes a (potential) security problem when the administrator removes all known copies of the (potentially vulnerable) suid program, and then believes the system is now "safe." |
IMHO it is unrealistic scenario. I never walk through the file system and looking for SUID files or their hardlinks.
If any single user is capable to create a hardlink, then even I remove them as an admin, they will be created over and over again. |
Only if the origin file still exists. If you remove the canonical copy of the vulnerable file, kill all the user's processes, and remove any unauthorized copies of the file, then the file is gone. More generally, this warning is because you shouldn't need to go hunting for suid files unless something strange has happened. In the normal case, there are no unexpected hard links. | lefsha wrote: | | If it was done by the root, then it's his responsibility to track it existence. Why would root not know about it in the first place? |
Who says the root action was done by a human administrator?
| lefsha wrote: | | You imagine a problem where none is existing. |
You fail to understand the creativity of attackers.
| lefsha wrote: | | Hu wrote: | | ...it does tell the user to go read the Gentoo Security Handbook. |
... which is not correct as I have mentioned earlier. I followed the advises there and broke my system. Nice. |
What exactly did you do that broke the system? The page advises against some changes because they are dangerous. Did it miss one? | lefsha wrote: | | I would suggest to remove those advises. |
Go ahead. Wikis are generally open to public comment and editing. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Dec 12, 2019 8:44 am Post subject: |
|
|
| Tony0945 wrote: | | Hu, can you enlighten us? |
And later: | Tony0945 wrote: | | No, I do not know why hardlinks are dangerous. |
Thank you, for having done so in the following posts. |
|
| Back to top |
|
|
lefsha
Veteran
Joined: 30 Aug 2004
Posts: 1234
Location: Burgas, Bulgaria
|
| Posted: Thu Dec 12, 2019 9:54 pm Post subject: |
|
|
| Hu wrote: | | your earlier posts give the impression that you think you know better than the people who wrote this software, yet you don't even seem to understand the problems they are trying to solve. |
Please, point me to my words where I do say explicitly I know something better? Please.
| Hu wrote: | | Haven't I done that several times already? |
Did I ever mention, that I've agreed on anything you have said? It is not enough just to say something. Enough is to convince other person
in what you have said. See the difference?
I am only talking for myself. If I am not able to convince you or any one else in what I am saying I don't claim that.
I don't say that everything has been said and your duty is to read it and to understand. We are not in a relation - professor <-> student.
Both of us! So you are in exactly the same position like me.
I repeat again:
| Hu wrote: | | Haven't I done that several times already? |
This is a nonsense!!! You blame me for being incorrect and instead you behave totally incorrect.
Until you understand, that this is a discussion between 2 persons in equal position there is no point to continue.
I do feel offended and I don't wish to continue.
As a topic starter, please, either change the rhetoric or stop writing here. Thank you in advance.
_________________
Lefsha |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
