This isn't a security bug as it requires root privilege to empty /etc/rc.conf. If you have root privilege, you can do that already. Also, changing the root shell is bad for many reasons and I'm not surprised that something doesn't work. That said, it certainly is less than desirable and should probably be more robust in case of this failure. I would recommend opening a bug for this and see if we can get someone to pick it up. Thanks for the report! Gordon Hat: security-officer On Sat, May 29, 2021 at 11:10 PM Fas Xmut via freebsd-security <freebsd-security at freebsd.org> wrote:> > I don't know if it is a security bug or not. When I use sysrc today, the error operations emptied my /etc/rc.conf, that's a small disaster, because my /etc/rc.conf is updated day by day, but now, it is empty. > > First, change your default root shell to sh/ksh or their derived shell. (I have tested, csh will not trigger that bug). > > Second, backup /etc/rc.conf to any other place. > > Then do the following commands: > > ------------------------------------------------------------------------ > # sysrc something_enable="NO" > # sysrc something_enable="YES > > " > awk: newline in string YES > ... at source line 1 > something_enable: NO -> YES > ------------------------------------------------------------------------ > > Now see what is inside /etc/rc.conf ? Everything is empty! only one thing in it: > > ------------------------------------------------------------------------ > something_enable="YES > " > ------------------------------------------------------------------------ > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > _______________________________________________ > freebsd-security at freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
> Also, changing the root shell is bad for many reasons and I'm not > surprised that something doesn't work.Surprised this old myth is still being repeated. Having used various root shells in FreeBSD and other Unux/Linux systems for decades I have to ask specifically what said reasons are, particularly considering /usr/sbin/sysrc starts with "#!/bin/sh" (as does and should every system shell script). Roger Marquis
01.06.2021 6:07, Roger Marquis wrote:>> Also, changing the root shell is bad for many reasons and I'm not >> surprised that something doesn't work. > > Surprised this old myth is still being repeated. Having used various > root shells in FreeBSD and other Unux/Linux systems for decades I have to > ask specifically what said reasons are, particularly considering > /usr/sbin/sysrc starts with "#!/bin/sh" (as does and should every system > shell script).Original statement was: "one should not change root shell to something like /usr/local/bin/bash" and/or "one should not change root shell at all" (unless one knows what he does). There are multiple ways for unexperienced root to breaks things changing its shell: - vipw allows one to make a misprint typing shell path name rendering root without a shell (so "toor" user was born); - /usr/local/bin/bash or any other shell residing on file system not mounted in single user mode and/or requiring libraries residing on not inaccessible file system, including NFS-mounted; - some historic scripts making assumptions on root shell behaviour etc. So it is much safer to create distinct non-root user with desired shell and use "su -m" that raises privileges but keeps user environment intact (HOME, shell, other environment).
> On May 31, 2021, at 16:07, Roger Marquis <marquis at roble.com> wrote: > > ? >> >> Also, changing the root shell is bad for many reasons and I'm not >> surprised that something doesn't work. > > Surprised this old myth is still being repeated. Having used various > root shells in FreeBSD and other Unux/Linux systems for decades I have to > ask specifically what said reasons are, particularly considering > /usr/sbin/sysrc starts with "#!/bin/sh" (as does and should every system > shell script).It?s likely due to the quoting behavior of newlines passed as the argument when he ran the script, which varies between shell implementations. As I said, I?m not surprised something broke because many utilities are not tested with different shell behaviors. I also believe if we have a reproducible test case, we should go ahead and fix it. Gordon