Is there a way to prevent root user from modifing kernel and boot loader?
up vote
0
down vote
favorite
Suppose that a regular linux machine is compromised by an attacker who obtained a root shell, he can modify the system kernel or modify boot loader to load another kernel.
Is there a way to prevent such modifications?
I want to disable such things for a regular linux os (not a container) installed on a regular pc with only one regular hard disk. I don't want to use read only mediums like cdrom.
A rough theoretical solution is to patch kernel to disallow modifications to MBR plus another area of hard disk (maybe a partition) and store kernel and boot loader files in that area.
linux kernel security root boot-loader
asked Dec 2 at 6:59
gopy
345
|
show 5 more comments
up vote
0
down vote
favorite
Suppose that a regular linux machine is compromised by an attacker who obtained a root shell, he can modify the system kernel or modify boot loader to load another kernel.
Is there a way to prevent such modifications?
I want to disable such things for a regular linux os (not a container) installed on a regular pc with only one regular hard disk. I don't want to use read only mediums like cdrom.
A rough theoretical solution is to patch kernel to disallow modifications to MBR plus another area of hard disk (maybe a partition) and store kernel and boot loader files in that area.
linux kernel security root boot-loader
asked Dec 2 at 6:59
gopy
345
1
UEFI secure boot, if that's supported by your "regular PC".
– Michael Homer
Dec 2 at 8:03
UEFI secure boot only detects the changes on reboot, it does not prevent. I'm looking for another solution.
– gopy
Dec 2 at 8:59
No you really can not limit root on a running os. If an intruder had physical or root access they can do what they wish. You can, however, use non root users rather than the root account. The only potential protections, imo, from exploits are keeping your system up to date and selinux ( selinux is not fool proof). You can read any linux security book or further hardening guides.
– Panther
Dec 2 at 16:12
It certainly prevents the “modify the boot loader to load another kernel” case, in that it won’t load another kernel, and module signing prevents injection into the running kernel. I’m not sure what your model is here.
– Michael Homer
Dec 2 at 17:03
@Panther I understand that root can do anything, but I mean to add changes to kernel that prevent root from doing the above mentioned actions. You advised to read about hardening methods, but I am looking for a new hardening method. It is a new layer of protection.
– gopy
Dec 2 at 17:27
|
show 5 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Suppose that a regular linux machine is compromised by an attacker who obtained a root shell, he can modify the system kernel or modify boot loader to load another kernel.
Is there a way to prevent such modifications?
I want to disable such things for a regular linux os (not a container) installed on a regular pc with only one regular hard disk. I don't want to use read only mediums like cdrom.
A rough theoretical solution is to patch kernel to disallow modifications to MBR plus another area of hard disk (maybe a partition) and store kernel and boot loader files in that area.
linux kernel security root boot-loader
asked Dec 2 at 6:59
gopy
345
Suppose that a regular linux machine is compromised by an attacker who obtained a root shell, he can modify the system kernel or modify boot loader to load another kernel.
Is there a way to prevent such modifications?
I want to disable such things for a regular linux os (not a container) installed on a regular pc with only one regular hard disk. I don't want to use read only mediums like cdrom.
A rough theoretical solution is to patch kernel to disallow modifications to MBR plus another area of hard disk (maybe a partition) and store kernel and boot loader files in that area.
linux kernel security root boot-loader
linux kernel security root boot-loader
asked Dec 2 at 6:59
gopy
345
asked Dec 2 at 6:59
gopy
345
asked Dec 2 at 6:59
gopy
345
asked Dec 2 at 6:59
gopy
345
asked Dec 2 at 6:59
gopy
345
345
1
UEFI secure boot, if that's supported by your "regular PC".
– Michael Homer
Dec 2 at 8:03
UEFI secure boot only detects the changes on reboot, it does not prevent. I'm looking for another solution.
– gopy
Dec 2 at 8:59
No you really can not limit root on a running os. If an intruder had physical or root access they can do what they wish. You can, however, use non root users rather than the root account. The only potential protections, imo, from exploits are keeping your system up to date and selinux ( selinux is not fool proof). You can read any linux security book or further hardening guides.
– Panther
Dec 2 at 16:12
It certainly prevents the “modify the boot loader to load another kernel” case, in that it won’t load another kernel, and module signing prevents injection into the running kernel. I’m not sure what your model is here.
– Michael Homer
Dec 2 at 17:03
@Panther I understand that root can do anything, but I mean to add changes to kernel that prevent root from doing the above mentioned actions. You advised to read about hardening methods, but I am looking for a new hardening method. It is a new layer of protection.
– gopy
Dec 2 at 17:27
|
show 5 more comments
1
UEFI secure boot, if that's supported by your "regular PC".
– Michael Homer
Dec 2 at 8:03
UEFI secure boot only detects the changes on reboot, it does not prevent. I'm looking for another solution.
– gopy
Dec 2 at 8:59
No you really can not limit root on a running os. If an intruder had physical or root access they can do what they wish. You can, however, use non root users rather than the root account. The only potential protections, imo, from exploits are keeping your system up to date and selinux ( selinux is not fool proof). You can read any linux security book or further hardening guides.
– Panther
Dec 2 at 16:12
It certainly prevents the “modify the boot loader to load another kernel” case, in that it won’t load another kernel, and module signing prevents injection into the running kernel. I’m not sure what your model is here.
– Michael Homer
Dec 2 at 17:03
@Panther I understand that root can do anything, but I mean to add changes to kernel that prevent root from doing the above mentioned actions. You advised to read about hardening methods, but I am looking for a new hardening method. It is a new layer of protection.
– gopy
Dec 2 at 17:27
1
1
UEFI secure boot, if that's supported by your "regular PC".
– Michael Homer
Dec 2 at 8:03
UEFI secure boot, if that's supported by your "regular PC".
– Michael Homer
Dec 2 at 8:03
UEFI secure boot only detects the changes on reboot, it does not prevent. I'm looking for another solution.
– gopy
Dec 2 at 8:59
UEFI secure boot only detects the changes on reboot, it does not prevent. I'm looking for another solution.
– gopy
Dec 2 at 8:59
No you really can not limit root on a running os. If an intruder had physical or root access they can do what they wish. You can, however, use non root users rather than the root account. The only potential protections, imo, from exploits are keeping your system up to date and selinux ( selinux is not fool proof). You can read any linux security book or further hardening guides.
– Panther
Dec 2 at 16:12
No you really can not limit root on a running os. If an intruder had physical or root access they can do what they wish. You can, however, use non root users rather than the root account. The only potential protections, imo, from exploits are keeping your system up to date and selinux ( selinux is not fool proof). You can read any linux security book or further hardening guides.
– Panther
Dec 2 at 16:12
It certainly prevents the “modify the boot loader to load another kernel” case, in that it won’t load another kernel, and module signing prevents injection into the running kernel. I’m not sure what your model is here.
– Michael Homer
Dec 2 at 17:03
It certainly prevents the “modify the boot loader to load another kernel” case, in that it won’t load another kernel, and module signing prevents injection into the running kernel. I’m not sure what your model is here.
– Michael Homer
Dec 2 at 17:03
@Panther I understand that root can do anything, but I mean to add changes to kernel that prevent root from doing the above mentioned actions. You advised to read about hardening methods, but I am looking for a new hardening method. It is a new layer of protection.
– gopy
Dec 2 at 17:27
@Panther I understand that root can do anything, but I mean to add changes to kernel that prevent root from doing the above mentioned actions. You advised to read about hardening methods, but I am looking for a new hardening method. It is a new layer of protection.
– gopy
Dec 2 at 17:27
|
show 5 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
'UEFI secure boot' would stop a remote attacker from persisting a reboot but they could just re-hack on every reboot.
Local users could just use
mokutil -#-import my_signing_key_pub.der
answered Dec 2 at 8:33
user1133275
2,675415
This is a comment to a previous comment not an answer
– Panther
Dec 2 at 16:35
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
'UEFI secure boot' would stop a remote attacker from persisting a reboot but they could just re-hack on every reboot.
Local users could just use
mokutil -#-import my_signing_key_pub.der
answered Dec 2 at 8:33
user1133275
2,675415
This is a comment to a previous comment not an answer
– Panther
Dec 2 at 16:35
add a comment |
up vote
1
down vote
'UEFI secure boot' would stop a remote attacker from persisting a reboot but they could just re-hack on every reboot.
Local users could just use
mokutil -#-import my_signing_key_pub.der
answered Dec 2 at 8:33
user1133275
2,675415
This is a comment to a previous comment not an answer
– Panther
Dec 2 at 16:35
add a comment |
up vote
1
down vote
up vote
1
down vote
'UEFI secure boot' would stop a remote attacker from persisting a reboot but they could just re-hack on every reboot.
Local users could just use
mokutil -#-import my_signing_key_pub.der
answered Dec 2 at 8:33
user1133275
2,675415
'UEFI secure boot' would stop a remote attacker from persisting a reboot but they could just re-hack on every reboot.
Local users could just use
mokutil -#-import my_signing_key_pub.der
answered Dec 2 at 8:33
user1133275
2,675415
answered Dec 2 at 8:33
user1133275
2,675415
answered Dec 2 at 8:33
user1133275
2,675415
answered Dec 2 at 8:33
user1133275
2,675415
2,675415
This is a comment to a previous comment not an answer
– Panther
Dec 2 at 16:35
add a comment |
This is a comment to a previous comment not an answer
– Panther
Dec 2 at 16:35
This is a comment to a previous comment not an answer
– Panther
Dec 2 at 16:35
This is a comment to a previous comment not an answer
– Panther
Dec 2 at 16:35
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485450%2fis-there-a-way-to-prevent-root-user-from-modifing-kernel-and-boot-loader%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
UEFI secure boot, if that's supported by your "regular PC".
– Michael Homer
Dec 2 at 8:03
UEFI secure boot only detects the changes on reboot, it does not prevent. I'm looking for another solution.
– gopy
Dec 2 at 8:59
No you really can not limit root on a running os. If an intruder had physical or root access they can do what they wish. You can, however, use non root users rather than the root account. The only potential protections, imo, from exploits are keeping your system up to date and selinux ( selinux is not fool proof). You can read any linux security book or further hardening guides.
– Panther
Dec 2 at 16:12
It certainly prevents the “modify the boot loader to load another kernel” case, in that it won’t load another kernel, and module signing prevents injection into the running kernel. I’m not sure what your model is here.
– Michael Homer
Dec 2 at 17:03
@Panther I understand that root can do anything, but I mean to add changes to kernel that prevent root from doing the above mentioned actions. You advised to read about hardening methods, but I am looking for a new hardening method. It is a new layer of protection.
– gopy
Dec 2 at 17:27