Date: Wed, 12 Aug 2020 10:03:44 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: Polytropon <freebsd@edvax.de> Cc: Yasuhiro KIMURA <yasu@utahime.org>, freebsd-questions@freebsd.org Subject: Re: GDB no workie? Permission problem? Message-ID: <72829.1597251824@segfault.tristatelogic.com> In-Reply-To: <20200812165931.702fd7ea.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20200812165931.702fd7ea.freebsd@edvax.de>, you wrote:
>On Tue, 11 Aug 2020 23:37:07 -0700, Ronald F. Guilmette wrote:
>> Thank you. The code seems to suggets that I just need to edit a
>> file called $BSDINSTALL_TMPBOOT/loader.conf.hardening but I will be
>> damned if I can find any such on my system, anywhere in my root
>> partition. So I'm stumped.
>
>You need to edit the _Actual_ loader configuration file,
>which is /boot/loader.conf;
Ahhhhh! OK. Done! Thank you.
>also have a look at the sysctl
>control file, /etc/sysctl.conf, as mentioned in my previous
>message - which did only arrive at the list, but not in your
>mailbox, as your ISP seems to block 1&1, Germany's probably
>most important ISP.
1&1 may be "important" but it is also a consistant source of
spam and does not respond in any manner that I would judge
to be "appropriate" to notifications regarding spam from
their network. Thus, they have been blocked locally.
>> To make matters even worse, the
>> output I get from "sysctl -a" doesn't even seem to list -any-
>> sysctl variable called "security.bsd.allow_destructive_dtrace", so
>> I am double stumped.
>
>Because it's not a DTrace problem - it's probably something
>else. Check
>
> % sysctl -a | grep security
>
>for all security-related variables; I'm sure you find one or
>two that deviate from the default setting.
Well, this is very odd indeed. In my /boot/loader.conf I did indeed
find a line that said:
security.bsd.allow_destructive_dtrace=0
(which I have now edited) however this command:
sysctl -a | grep security.bsd
yields only:
security.bsd.stack_guard_page: 1
security.bsd.unprivileged_get_quota: 0
security.bsd.hardlink_check_gid: 0
security.bsd.hardlink_check_uid: 0
security.bsd.unprivileged_idprio: 0
security.bsd.unprivileged_proc_debug: 0
security.bsd.conservative_signals: 1
security.bsd.see_jail_proc: 1
security.bsd.see_other_gids: 1
security.bsd.see_other_uids: 1
security.bsd.unprivileged_read_msgbuf: 0
security.bsd.unprivileged_mlock: 1
security.bsd.suser_enabled: 1
security.bsd.map_at_zero: 0
It seems apparent to me that security.bsd.unprivileged_proc_debug
is the sysctl variable of interest here, however I am still
mystified as to why changinging the value of:
security.bsd.allow_destructive_dtrace
(via the /boot/loader.conf file) would affect this different
named variable, security.bsd.unprivileged_proc_debug. I can
only guess that it this must be due to some sort of backward
compatability magic that I am not aware of.
In any case, I need to reboot now and see if my edit to my
/boot/loader.conf file has accomplished the change I desire.
Regards,
rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72829.1597251824>