Slashdot Mirror
Systemd Absorbs "su" Command Functionality
jones_supa writes: With a pull request systemd now supports a su command functional and can create privileged sessions that are fully isolated from the original session. The su command is seen as bad because what it is supposed to do is ambiguous. On one hand it's supposed to open a new session and change a number of execution context parameters, and on the other it's supposed to inherit a lot concepts from the originating session. Lennart Poettering's long story short: "`su` is really a broken concept. It will given you kind of a shell, and it's fine to use it for that, but it's not a full login, and shouldn't be mistaken for one." The replacement command provided by systemd is machinectl shell.
Just like he considers exit statuses, stderr, and syslog "broken concepts." That is why systemd supports them so poorly. He just doesn't understand why those things are critical. An su system that doesn't properly log to syslog is a serious security problem.
machinectl shell is only incidentally similar to su. Its primary purpose is to establish an su-like session on a different container or VM. Systemd refers to these as 'machines', hence the name machinectl.
http://www.freedesktop.org/sof...
su cannot and does not do that sort of thing. machinectl shell is more like a variant of rsh than a replacement for su.
Did an editor even glance at this piece of crap before it was posted?
a su command functional
a) "an su." Write it like you'd say it.
b) what's a "command functional"?
c) you've got all the right words... just not necessarily in the right order
a lot concepts
I think you accidentally a word.
It will given you kind of a shell
Can it has cheezeburger too?
systemd is Roko's Basilisk.
OpenRC++
openrc init scripts are fairly straight forward.
Coupled with gentoo's baselayout, and the config file layout is fairly normalized also.
> 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.