Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Aug 2020 16:59:31 +0200
From:      Polytropon <freebsd@edvax.de>
To:        "Ronald F. Guilmette" <rfg@tristatelogic.com>
Cc:        Yasuhiro KIMURA <yasu@utahime.org>, freebsd-questions@freebsd.org
Subject:   Re: GDB no workie? Permission problem?
Message-ID:  <20200812165931.702fd7ea.freebsd@edvax.de>
In-Reply-To: <69681.1597214227@segfault.tristatelogic.com>
References:  <20200811.022654.1924978480022516137.yasu@utahime.org> <69681.1597214227@segfault.tristatelogic.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Aug 2020 23:37:07 -0700, Ronald F. Guilmette wrote:
> In message <20200811.022654.1924978480022516137.yasu@utahime.org>, you wrote:
> 
> >From: "Ronald F. Guilmette" <rfg@tristatelogic.com>
> >Subject: GDB no workie? Permission problem?
> >Date: Mon, 10 Aug 2020 10:01:03 -0700
> >
> >> I seem to vaguely recall some "security" options being presented
> >> at system install time, and I do believe one of these had to do
> >> with ptrace.  So I guess that I must have made the Wrong Choice
> >> with respect to that one. OK. Fine.  Now how do I fix that misake
> >> on my part, short of re-installing the whole bloody system?
> >
> >"System Hardening" stage of installation is handled by
> >/usr/libexec/bsdinstall/hardening and it is shell script. So if you
> >understand syntax of bourne shell you can undo your system hardening
> >settings by reading it.
> 
> 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; 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.

I wrote (on Mon, 10 Aug 2020 20:41:40 +0200):

On Mon, 10 Aug 2020 10:01:03 -0700, Ronald F. Guilmette wrote:
> Just ran gdb, which I haven't done for awhile, to find a small
> bug in one of my own C programs.
> 
> Set two breakpoints successfully and then tried to r(un) the
> program to be debugged.  (This was all being done under my
> own personal non-priviliged account.)
> 
> Immediately got something very unexpected:
> 
>     warning: Could not trace the inferior process.
>     Error: 
>     warning: ptrace: Operation not permitted
>     During startup program exited with code 127.
> 
> I su'd to root and tried again, and of course now it works.
> 
> So, um, what the hay? What goes on here?
> 
> I seem to vaguely recall some "security" options being presented
> at system install time, and I do believe one of these had to do
> with ptrace.  So I guess that I must have made the Wrong Choice
> with respect to that one. OK. Fine.  Now how do I fix that misake
> on my part, short of re-installing the whole bloody system?

Yes, that seems to be the case here. At installation stage,
certain options would have been set in the relevant configuraiton
files, but there's noting requiring a re-installation - you can
undo those changes with a simple text editor. :-)

Check the following files:

	/boot/loader.conf
	/etc/sysctl.conf	<--- probably this one
	/etc/rc.conf

I'm sure you'll find something related to security restrictions,
such as those:

	security.bsd.unprivileged_read_msgbuf=0
	security.bsd.unprivileged_proc_debug=0
	security.bsd.see_other_uids=0

As suggested by Yasuhiro Kimura, there are several settings that
could have been applied. See the following file to find their
names and settings:

	/usr/libexec/bsdinstall/hardening

You can use sysctl interactively, or just edit the files and
reboot the system so they take effect.

* * * end quote * * *



> 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.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200812165931.702fd7ea.freebsd>