Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Building the kernel as root can be harmful
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
nicop06
n00b
n00b


Joined: 25 May 2017
Posts: 13
Location: France

PostPosted: Thu May 25, 2017 1:28 pm    Post subject: Building the kernel as root can be harmful Reply with quote

I recently came across this video from Greg Kroah-Hartman where he pointed out a bug in the kernel build that would completely delete /. I double checked in the Gentoo wiki about kernel configuration and genkernel and it is clearly indicated to build it as root.

I know what some could say: if you don't want to build it as root, don't do it. This is not my point. I for one perform hourly BTRFS snapshots of my system, so I can recover a complete wipe out of my root partition in minutes.

I was wondering if there ever was a discussion about using the sandboxing mechanism of portage (for instance) to build the Kernel, at least when using genkernel. Among all the Linux distribution I have used (I insist on Linux, as that's not the case on BSD), Gentoo is the only one building the kernel differently.

I myself enjoy the fact that the kernel is directly present in /usr/src to quickly change kernel configuration (I don't even use genkernel). But doing for instance
Code:
runsandbox make
instead of
Code:
make
could make thinks safer without any noticeable drawback except a few extra keystrokes.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6503

PostPosted: Fri May 26, 2017 12:46 am    Post subject: Reply with quote

The kernel supports out-of-tree builds:
Code:
$ cd ~/kbuild-foo && make -C /usr/src/linux O=`pwd` oldconfig
$ make oldconfig && make && sudo make modules_install install #etc

You can "sandbox" that as uid=nobody trivially without ever writing a single byte to /usr/src/ (and thus depclean can do its job properly); Portage's sandbox is overkill and you certainly don't need to bring the insanity of the likes of make-kpkg into it.
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10308
Location: Córdoba (Spain)

PostPosted: Fri May 26, 2017 11:08 am    Post subject: Reply with quote

Thankfully, Gentoo has ways to deal with this idiotic default.

The first thing I ever do in a new install is

Code:
$ echo "sys-kernel/gentoo-sources-9999" > /etc/portage/profile/package.provided
# and then
$ ln -s <kernel_source_tree> /usr/src/linux>


Then you can host as many kernels as you want in your home and portage will be happy. Bear in mind that you need to ln -nsf the kernel tree again each time you swap your kernel, to prevent problems with some packages that will include header files from the kernel tree. We all know they should be looking at kernel-headers instead, but... Plus Gentoo instaurated that trend where packages will look into your kernel config file to see if you have nor not support for featureX (which is pretty dumb because the location of featureX changes on every kernel release and you will misleading ewarns all around anyway).

All you need to do as root is make install modules_install, plus the bootloader configuration, of course.
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4544
Location: Dallas area

PostPosted: Fri May 26, 2017 1:02 pm    Post subject: Reply with quote

i92guboj wrote:
All you need to do as root is make install modules_install, plus the bootloader configuration, of course.


I have a dummy kernel that I use (but I like the packages provided way)
I lay down my own sources (zen) and compile as user, then sudo or become root for make modules_install and make install.
_________________
PRIME x570-pro, 3700x, RX 550 & 560
Acer E5-575 (laptop), i3-7100u - i965
---both---
5.5.18 zen kernel, gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10308
Location: Córdoba (Spain)

PostPosted: Fri May 26, 2017 2:20 pm    Post subject: Reply with quote

Anon-E-moose wrote:
i92guboj wrote:
All you need to do as root is make install modules_install, plus the bootloader configuration, of course.


I have a dummy kernel that I use (but I like the packages provided way)
I lay down my own sources (zen) and compile as user, then sudo or become root for make modules_install and make install.


The sane way to do it. Compiling as root is not any better (in fact, it might be much worse) than running an X server as root, something every single guide around the net says you shouldn't do.
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15336

PostPosted: Sat May 27, 2017 12:17 am    Post subject: Reply with quote

To go one step further, you can set $INSTALL_PATH and $INSTALL_MOD_PATH prior to running make install / make modules_install to get approximately the same effect as $DESTDIR on autotools packages. This lets an unprivileged user install to a staging area, which root then copies to the live filesystem. This can be convenient if you build one kernel for several machines.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 783
Location: usually offline

PostPosted: Sat May 27, 2017 10:14 am    Post subject: Reply with quote

gentoo was the first distro officially asking users to kernel compile as root. i have used many other distros, and recommendation has always been to compile kernel as normal user. thanks for this thread.
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 309

PostPosted: Sat May 27, 2017 10:24 am    Post subject: Reply with quote

There are a number of ways to avoid building the kernel as root, my approach is to have a kernel_builder user and chown the /usr/src/linux tree to that user and then build the kernel, I do this at install stage and then just continue this method while maintaining the system. I think it would be good to include a non-root method of building the kernel in the handbook and encourage users to take that approach. I don't know which method would be the best ... but I guess most would be better than building the kernel as root.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1499

PostPosted: Sat May 27, 2017 2:47 pm    Post subject: Reply with quote

Interesting...this whole topic is news to me. I've always done this as part of my updates as root.
Ant P. wrote:
The kernel supports out-of-tree builds:
Code:
$ cd ~/kbuild-foo && make -C /usr/src/linux O=`pwd` oldconfig
$ make oldconfig && make && sudo make modules_install install #etc


I like that approach. I was just trying that in a directory in my home. However it failed with:
Code:
/usr/src/linux-4.9.16-gentoo is not clean, please run 'make mrproper'
I'm assuming that's because the kernel was already built in that source directory, and that doing this would in fact work after a clean emerge of a new gentoo-sources version? Thanks!

Tom
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7415

PostPosted: Sat May 27, 2017 3:59 pm    Post subject: Reply with quote

bah, you're paranoid for me, everything could be harmful, the kernel is not made to delete / but a bug could had done that.
if you're scary about shit happening, use backup, but if you start sandboxing kernel because build could have a bug in it, you'll sandbox every tools you could use, because, a bug is not a feature, and all tools could have one.

at end, you have secure everything with sandbox, to see a sandbox bug deleting all your datas :)

i'm not saying nobody shouldn't take a bit of care, specially when root, but you have to trust the tools a bit, the time you lost in taking care of everything would be better invest in backing up your datas.

there's also something odd there: if i lost root, i'm good for a reinstall, bah, time lost on reconfiguring everything etc... but if i lost my home, i'll lost my datas that i care for, hence i find odd someone prefer using a user.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15336

PostPosted: Sat May 27, 2017 4:33 pm    Post subject: Reply with quote

A dedicated kernel build user can protect the user's regular data. A build bug that deletes / would likely also delete all user home directories.

Clever use of namespaces to isolate the build system so it cannot modify outside its intended area can also mitigate such problems.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1759

PostPosted: Sat May 27, 2017 5:16 pm    Post subject: Reply with quote

I agree with krinn as you need to trust something; as anything can have a bug in it that could destroy everything. In the end, running as root is always dangerous hence why it is recommended to use root only when it is necessary.

Either way, it is better to keep backups (the more important stuff have multiple backup copies) so you can recover when something happens. In the end, one of the more common sources of problems is what is behind the keyboard (which I would love to see a patch to fix that :) )
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6503

PostPosted: Sat May 27, 2017 5:23 pm    Post subject: Reply with quote

tld wrote:
However it failed with:
Code:
/usr/src/linux-4.9.16-gentoo is not clean, please run 'make mrproper'
I'm assuming that's because the kernel was already built in that source directory, and that doing this would in fact work after a clean emerge of a new gentoo-sources version? Thanks!

The command it gave should work (save your .config somewhere safe first if necessary), no need for reemerge. For anyone using a git clone of the kernel `git clean -xfd` should work too.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7415

PostPosted: Sat May 27, 2017 5:31 pm    Post subject: Reply with quote

i would (which i'm not doing) prefer just remount /home ro while building a kernel to prevent it from getting harm.

gkh article is about : hey don't trust us blindly as we can harm your system too ; but it's something you are force to do everyday else you'll loose a lot of time.

you take back your car from garage ; you don't remove all parts of the car to check what has been done
you drop a letter in the letterbox, you don't take a plane to follow the letter
you put your paycheck to the bank, you're not checking all the guys to see if one will steal your money

sure you can follow the letter or check your account if your money is there, but it's a check if something bad has happen, not a check if something bad will happen.
because if one would do that, it would really be better to check the car, as you might endup in a wall to figure out you shouldn't had trust him, but really, who do that?

so, you just build your kernel as root, and you suppose nobody is trying to harm you
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 309

PostPosted: Sat May 27, 2017 9:48 pm    Post subject: Reply with quote

krinn wrote:
there's also something odd there: if i lost root, i'm good for a reinstall, bah, time lost on reconfiguring everything etc... but if i lost my home, i'll lost my datas that i care for, hence i find odd someone prefer using a user.

I chown /usr/src/linux to a user kernel_builder who is able to:-
Code:
sudo chown /usr/src/linux -R
sudo make modules_install

Everything else that user does without root rights. So if things go completely wrong with the build process then I could loose /usr/src/linux.
My important user data (which kernel_builder can't even see) is safe ... as is the offline backup of the user data.

There is no need to build the kernel as root ... for me the simple rule is run with minimum right, as far as root is concerned:-
1. If it does not need to run as root then don't.
2. If it needs to run as root question why.

I go further than this and use separate user accounts for emails, surfing the net, online banking etc. That's my choice - I don't want or need to force others to do the same. Running things as root which do not require it does not fall into the good practice category ... so IMHO the handbook should not be encouraging it.
Back to top
View user's profile Send private message
nicop06
n00b
n00b


Joined: 25 May 2017
Posts: 13
Location: France

PostPosted: Sun May 28, 2017 12:45 am    Post subject: Reply with quote

Thank you for all those interesting replies. As I explained, I am paranoid about backup, which paid of as I've used them multiple time. I encourage everyone to do the same (a simple rsync crontab takes 5 minutes to setup). My main problem was about documentation, especially for new comers.

I myself recently switched to Gentoo 2 years ago and with that started to build the kernel. At the time I never questioned the handbook. After hearing this remark from GKH, I realized how contradictory Gentoo is concerning packages.

In Arch (or Alpine, or Void), all packages are built without any sandbox as regular user, including the kernel. In Gentoo, all the builds are sandboxed except the kernel which is built as root, and there should be a middle ground. I know, I can't imagine any kernel developer purposely adding code to harm your system when you build it as root (they can do it in much more subtle ways if they modify the kernel core part). But Linux has a large code base and as anyone knows bugs are unavoidable and hard to predict in that case.

I think there should be more information about building the kernel as a regular user. Your suggestions about out of tree build or using a kernel build user are exactly what I had in mind when I wrote the post and may be added to the wiki. Also, as it has been pointed out, current model where some packages read /usr/src/linux can be improved. Maybe we can install kernel headers to build other packages instead of reading them in the source, and maybe read the config from /boot (or other places).

I mainly wanted some opinion to see if it was worth opening an issue to Gentoo DEV to see how it can be improved. My point being, if it's something we should all do and it's not enforced or encouraged by the distribution nobody will do it.

By the way, anyone noticed the bug described by GKH? It might be really old , I am just asking out of curiosity.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7415

PostPosted: Sun May 28, 2017 12:57 am    Post subject: Reply with quote

jonathan183 wrote:
Everything else that user does without root rights. So if things go completely wrong with the build process then I could loose /usr/src/linux.

So, because you don't trust kernel build process, you use sudo to covert you. Everything could bug, but not sudo!

Because you don't trust one program, you add another one, you must now trust two programs :)
In fact it's worst, if kernel build bug, you're not 100% sudo will prevent you from that bug, but even if kernel build doesn't, you cannot be sure of what sudo could do.

If sudo is 100% sure in your mind, it looks a very good way (assuming you're 100% sure also, that not only sudo is safe itself, but it will indeed prevent kernel bug to harm you).
The question is: where that 100% trust on sudo comes from? You need a video from a dev that says "hell, we have done shit with sudo one day" to review your blind trust on it?

nicop06 wrote:
I mainly wanted some opinion to see if it was worth opening an issue to Gentoo DEV to see how it can be improved

It might enlight up a bit your view on it knowing this no? https://wiki.gentoo.org/wiki/User:GregKH
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1759

PostPosted: Sun May 28, 2017 1:08 am    Post subject: Reply with quote

One part you are going need to keep an eye on, is that other packages do compile against the kernel sources too. Those emerge processes are sandboxed, so may not have the privilages to access the compiled files...

As far as documenting about this, think about what all you had to do to compile the kernel sources as a user (non-root). Most of those steps would have to be completely redone each time you get a new kernel source; as portage just downloads the new kernel sources into their own folder seperate from other kernel sources (/usr/src/linux is just a sym link to the selected kernel's folder).
Back to top
View user's profile Send private message
nicop06
n00b
n00b


Joined: 25 May 2017
Posts: 13
Location: France

PostPosted: Sun May 28, 2017 12:06 pm    Post subject: Reply with quote

krinn wrote:
So, because you don't trust kernel build process, you use sudo to covert you. Everything could bug, but not sudo!


Well, I don't think that's what he meant. Sudo is not enforcing access rights. Paradoxically, the kernel is. But security concerning this part of the kernel is carefully reviewed while the build process is not. It's easy to add this:

Code:
rm -rf $PATH_TO_SOURCE/


Someone put this line on on crontab on the NAS of my company once. The variable was set on a configuration file which was changed. The crontab deleted all the files that were writable by all users daily. Imagine if the user was root.

And, even if sudo was the problem, I doubt there are as many people involved in the sudo development than there is in the kernel.

But I understand your point, and it's good to have both side of the debate.

krinn wrote:
It might enlight up a bit your view on it knowing this no? https://wiki.gentoo.org/wiki/User:GregKH


Good to know

ct85711 wrote:

As far as documenting about this, think about what all you had to do to compile the kernel sources as a user (non-root). Most of those steps would have to be completely redone each time you get a new kernel source; as portage just downloads the new kernel sources into their own folder seperate from other kernel sources (/usr/src/linux is just a sym link to the selected kernel's folder).


That's the point, portage could install the source as a non-root user (like portage?). Also, I think most user have a script to upgrade the kernel (genkernel being one). Otherwise, it's very easy to miss a step and have an unbootable system.
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 309

PostPosted: Sun May 28, 2017 1:16 pm    Post subject: Reply with quote

krinn wrote:
So, because you don't trust kernel build process, you use sudo to covert you. Everything could bug, but not sudo!

Because you don't trust one program, you add another one, you must now trust two programs :)
In fact it's worst, if kernel build bug, you're not 100% sudo will prevent you from that bug, but even if kernel build doesn't, you cannot be sure of what sudo could do.

If sudo is 100% sure in your mind, it looks a very good way (assuming you're 100% sure also, that not only sudo is safe itself, but it will indeed prevent kernel bug to harm you).
The question is: where that 100% trust on sudo comes from? You need a video from a dev that says "hell, we have done shit with sudo one day" to review your blind trust on it?


OK so if I don't trust sudo then changes are:-
as root chown to kernel_builder /usr/src/linux
configure and build kernel as limited user kernel_builder
as root make modules_install

The point is I will still do only what is needed as root - I think that is a good principle to follow.

The handbook could be improved for kernel building, I know a way which works better for me - I don't know the best way of doing this otherwise I would have suggested an update to the handbook.
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10308
Location: Córdoba (Spain)

PostPosted: Sun May 28, 2017 1:19 pm    Post subject: Reply with quote

Hu wrote:
To go one step further, you can set $INSTALL_PATH and $INSTALL_MOD_PATH prior to running make install / make modules_install to get approximately the same effect as $DESTDIR on autotools packages. This lets an unprivileged user install to a staging area, which root then copies to the live filesystem. This can be convenient if you build one kernel for several machines.


Yes. You can do a lot of things to complicate a simple thing. Truly smart.
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15336

PostPosted: Sun May 28, 2017 3:07 pm    Post subject: Reply with quote

I find the use of $INSTALL_PATH / $INSTALL_MOD_PATH to be simpler and more reliable than trying to track down all the files installed by make install modules_install as root. I consider the rise of $DESTDIR and equivalent in other build systems to be evidence that other people likewise prefer to install to a clean staging area and record its state rather than install directly into the live environment and try to guess the state afterward. This approach also has the benefits that there is no need to chown anything before building and that you can review exactly what will be installed using standard directory tools. As mentioned previously, this is also very helpful if the kernel is built on one machine, then installed on a different one.

The only drawback I see to an out-of-source build like this is that, as mentioned by ct85711, many packages expect to dig around in a prepared /usr/src/linux to guess what state the running kernel will have. I find this approach to be well-intentioned, but frequently counterproductive. It is a concern for some users, and would need to be mentioned as a caution for any instructions on out-of-tree builds.
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10308
Location: Córdoba (Spain)

PostPosted: Sun May 28, 2017 3:22 pm    Post subject: Reply with quote

There's nothing to track down. Kernel goes into /usr/src/linux. Modules goes into /usr/lib/modules

You can hack all you want. But, at the end of the day, rm is all you need. :)
_________________
Gentoo Handbook | My website
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 7687
Location: Saint Amant, Acadiana

PostPosted: Sun May 28, 2017 3:41 pm    Post subject: Reply with quote

I used to download sources to my home and build the kernel as user when I was running Debian, then copied it over as root. It is a little more complicated with Gentoo if you want to apply gentoo-patches. Still no rocket science.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 309

PostPosted: Sun May 28, 2017 4:39 pm    Post subject: Reply with quote

Hu wrote:
I find the use of $INSTALL_PATH / $INSTALL_MOD_PATH to be simpler and more reliable than trying to track down all the files installed by make install modules_install as root. I consider the rise of $DESTDIR and equivalent in other build systems to be evidence that other people likewise prefer to install to a clean staging area and record its state rather than install directly into the live environment and try to guess the state afterward. This approach also has the benefits that there is no need to chown anything before building and that you can review exactly what will be installed using standard directory tools. As mentioned previously, this is also very helpful if the kernel is built on one machine, then installed on a different one.

The only drawback I see to an out-of-source build like this is that, as mentioned by ct85711, many packages expect to dig around in a prepared /usr/src/linux to guess what state the running kernel will have. I find this approach to be well-intentioned, but frequently counterproductive. It is a concern for some users, and would need to be mentioned as a caution for any instructions on out-of-tree builds.


OK so now I am thinking what may work best for me is:-
as root (for a fresh install) create kernel_builder user
as root (or using sudo) chown /usr/src/linux to my kernel_builder user

then as my kernel_builder user
create /usr/src/linux/My_INSTALL_PATH and /usr/src/linux/My_INSTALL_MOD_PATH
configure and build kernel
export INSTALL_PATH=/usr/src/linux/My_INSTALL_PATH
export INSTALL_MOD_PATH=/usr/src/linux/My_INSTALL_MOD_PATH
make install
make modules_install

then as root (or using sudo) copy kernel and modules to required folders

Advantages - whole build process including installing modules is done as limited user kernel_builder.
If I want to review anything before transfer to /boot /lib/modules I can do, and other tools/packages looking for things in /usr/src/linux will find them 8)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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