Lennart Poettering's long story short: "`su` is really a broken concept
Declaring established concepts as broken so you can "fix" them.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.
If you need a full login you invoke 'su -' or 'sudo bash -'
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
by Anonymous Coward writes:
on Saturday August 29, 2015 @12:27PM (#50416069)
If you want a FULL shell Oh I dont know 'su bash' usually works pretty fng good...
It does if you are fine to only get root privilege, without FULL environment of root. But if you would have to make sure you have FULL root environment, first discarding anything you had in calling user and then executing root users environment (/etc/profile etc.) you better use "su - bash" or "sudo -i". Compare what you get both ways "su bash" vs "su - bash" with runnint "set" and "env" commands, please.
Failing to have FULL root environment, can have security implications (umask, wrong path, wrong path order,...) which may or may not be critical depending what system you are operating and to whom. Also some commands may fail or misbehave just because of path differences etc.
Above is trivial information and should be clear without further explanation anyone running *nix systems for someone else as part of job ie. work professionally on the field. Incase you don't, it's still useful information you should learn about sysadmin of the platform you happen to use.
change root (chroot) is almost as easy to undo as change directory (cd) . You can ALWAYS "break out" of chroot. The only thing making it inconvenient is if you don't know the syntax to refer to the new root you'd like to change to.
Chroot is not for security, it was never designed for security, and if your suckurity depends on chroot you are Doing It Wrong.
> In short: I think chroot is plenty good for security
Check man chroot. The authors of chroot say it's useless for security. Perhaps you think you know more than they do,and more than security professionals like myself do. Let's find out.
> you get a shell in one of my chroot's used for security, then..... ur uid and gid are not going to be 0. Good luck telling the kernel to try and get you out. There aren't going to be any/dev,/proc, or other special filesystems
Gonna be kind of tthough to have a ahell without a tty, aka/dev/*tty* So yeah, you need/dev. Can't launch a process, including/bin/ls, without/proc, so you're going to need proc. Have a look in/proc/1. You'll see a very interesting symlink there.
> mounted noexec
Noexec is basically a suggestion, not an enforement mechanism . Just run ld/path/to/executable. ld is the loader/lilinker for elf binaries. Without ld,you can't run bash, or ls. With ld, noexec is ignored.
My company does IT security for banks. Meaning we show the banks how they can be hacked. When I say chroot is not a security control, I'm not guessing.
Wasn't the point that chroot is as good, and not better, as the normal Unix permission/groups security feature? So, basically, chroot doesn't and isn't designed to add any additional security besides the normal Unix permission/groups security.
This means using a chroot is not less secure, but it is not more secure either. If you have proper permissions configured on your system, you are no safer inside a chroot than relying on system permissions to keep a user in check.
Noexec is basically a suggestion, not an enforement mechanism . Just run ld/path/to/executable. ld is the loader/lilinker for elf binaries. Without ld,you can't run bash, or ls. With ld, noexec is ignored.
chroot may be useless for security. Do you think the ever more popular containers such as docker and openvas are also useless for security? I almost look at them as a more secure and better chroot and use them as such.
> Do you think the ever more popular containers such as docker and openvas are also useless for security?
I rate them as "not proven". Now that lx containers can run as regular users, they are _intended_ to enforce some separation. The purpose for the which chroot was designed was to avoid the need to set basedir in every makefile of a build system. It's a convenience feature roughly equivalent to ln -s/mnt/test// Much like cd which internally looks like: ln -s ./somewhere
> Just run ld/path/to/executable. ld is the loader/lilinker for elf binaries. Without ld,you can't run bash, or ls. With ld, noexec is ignored.
Hasn't that been made a lot more difficult since 2.6?
I just tried it on my machine, running 4.2.0-rc7, and got: "./bash: error while loading shared libraries:./bash: failed to map segment from shared object"
Sounds like you're someone who thinks they know about security. You probably do know something, not as much as you think.
I want you to look it up and admit your error. Chroot is easy to break out of if you know what you're doing. Don't feel bad, however. I have to correct people on this a lot. Often by showing them. Solaris, Irix, Linux, doesn't matter. It's not a jail. For what it was designed for it works well.
I'm not going to show how to do this on slashdot. I get paid to do that, however it's out the
Sounds to me like you are banking on kernel exploits being more rare than they actually are.
Well, from a chroot environment running as a non-root user: it is going to be a technical challenge to make calls to the kernel directly, and for all you know a syscall filtering mechanism is in place, And chroot is just one of the early lines of defense.
Bullshit (Score:5, Insightful)
Lennart Poettering's long story short: "`su` is really a broken concept
Declaring established concepts as broken so you can "fix" them.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.
If you need a full login you invoke 'su -' or 'sudo bash -'
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
Re: (Score:0)
If you want a FULL shell
Oh I dont know 'su bash' usually works pretty fng good...
Re:Bullshit (Score:5, Interesting)
If you want a FULL shell
Oh I dont know 'su bash' usually works pretty fng good...
It does if you are fine to only get root privilege, without FULL environment of root. But if you would have to make sure you have FULL root environment, first discarding anything you had in calling user and then executing root users environment (/etc/profile etc.) you better use "su - bash" or "sudo -i". Compare what you get both ways "su bash" vs "su - bash" with runnint "set" and "env" commands, please.
Failing to have FULL root environment, can have security implications (umask, wrong path, wrong path order, ...) which may or may not be critical depending what system you are operating and to whom. Also some commands may fail or misbehave just because of path differences etc.
Above is trivial information and should be clear without further explanation anyone running *nix systems for someone else as part of job ie. work professionally on the field. Incase you don't, it's still useful information you should learn about sysadmin of the platform you happen to use.
Re: (Score:2)
Ok. Do you want someone to be able to break out of a chroot or jail, using [alternativetosu] ? Because you might not want that...
chroot is not for security. like change directory (Score:1)
change root (chroot) is almost as easy to undo as change directory (cd) . You can ALWAYS "break out" of chroot. The only thing making it inconvenient is if you don't know the syntax to refer to the new root you'd like to change to.
Chroot is not for security, it was never designed for security, and if your suckurity depends on chroot you are Doing It Wrong.
Re: (Score:3, Informative)
You can ALWAYS "break out" of chroot.
If you get a shell in one of my chroot's used for security, then.....
Re: (Score:2)
read the man page (Score:5, Informative)
> In short: I think chroot is plenty good for security
Check man chroot. The authors of chroot say it's useless for security. ,and more than security professionals like myself do. Let's find out.
Perhaps you think you know more than they do
> you get a shell in one of my chroot's used for security, then..... /dev, /proc, or other special filesystems
ur uid and gid are not going to be 0. Good luck telling the kernel to try and get you out.
There aren't going to be any
Gonna be kind of tthough to have a ahell without a tty, aka /dev/*tty* /dev. Can't launch a process, including /bin/ls, without /proc, so you're going to need proc. Have a look in /proc/1. You'll see a very interesting symlink there.
So yeah, you need
> mounted noexec
Noexec is basically a suggestion, not an enforement mechanism . Just run ld /path/to/executable. ld is the loader/lilinker for elf binaries. Without ld ,you can't run bash, or ls. With ld, noexec is ignored.
My company does IT security for banks. Meaning we show the banks how they can be hacked. When I say chroot is not a security control, I'm not guessing.
Re: (Score:3)
Wasn't the point that chroot is as good, and not better, as the normal Unix permission/groups security feature? So, basically, chroot doesn't and isn't designed to add any additional security besides the normal Unix permission/groups security.
This means using a chroot is not less secure, but it is not more secure either. If you have proper permissions configured on your system, you are no safer inside a chroot than relying on system permissions to keep a user in check.
https://securityblog.redhat.co... [redhat.com]
Re: (Score:2)
Noexec is basically a suggestion, not an enforement mechanism . Just run ld /path/to/executable. ld is the loader/lilinker for elf binaries. Without ld ,you can't run bash, or ls. With ld, noexec is ignored.
Wow, I wish I'd known that four years ago.
Re: (Score:1)
Re: (Score:2)
> Do you think the ever more popular containers such as docker and openvas are also useless for security?
I rate them as "not proven". Now that lx containers can run as regular users, they are _intended_ to enforce some separation. /mnt/test/ / /somewhere
The purpose for the which chroot was designed was to avoid the need to set basedir in every makefile of a build system. It's a convenience feature roughly equivalent to
ln -s
Much like cd which internally looks like:
ln -s .
LX containers are at l
Re: (Score:1)
Hasn't that been made a lot more difficult since 2.6?
I just tried it on my machine, running 4.2.0-rc7, and got: "./bash: error while loading shared libraries:
Re: (Score:2)
Gonna be kind of tthough to have a ahell without a tty, aka /dev/*tty*So yeah, you need /dev.
False. In fact you're false on so many counts, that I'll just show with a session excerpt to a jailed shell.
[~]# uname -ir /etc/passwd /var/jail/etc/passwd /proc/uptime
2.6.32-573.1.1.el6.x86_64 x86_64 [~]# grep support1
support1:x:1411:1411::/var/jail/./home/support1:/usr/sbin/jk_chrootsh
[~]# grep support1
support1:x:1411:1411::/home/support1:/bin/bash
[~]# cat
246835.99 239072.52
[~]# su - support1
[~]$ ca
Re: (Score:1)
Sounds like you're someone who thinks they know about security. You probably do know something, not as much as you think.
I want you to look it up and admit your error. Chroot is easy to break out of if you know what you're doing. Don't feel bad, however. I have to correct people on this a lot. Often by showing them. Solaris, Irix, Linux, doesn't matter. It's not a jail. For what it was designed for it works well.
I'm not going to show how to do this on slashdot. I get paid to do that, however it's out the
Re: (Score:2)
Sounds to me like you are banking on kernel exploits being more rare than they actually are.
Well, from a chroot environment running as a non-root user: it is going to be a technical challenge to make calls to the kernel directly, and for all you know a syscall filtering mechanism is in place, And chroot is just one of the early lines of defense.
Re: (Score:2)