Re: bind commands in ENV file cause spurious warnings by security(8)

[Lari Rasku]

Jeremie Courreges-Anglas kirjoitti 11/01/17 klo 15:03:
> Obviously x_init_emacs does more than than just set x_tty.
I should've been clearer; obviously I didn't mean to call all of 
x_init_emacs vestigial code, just the x_tty set-test code path through 
it.  But you're right, I was too eager - nixing it is not a good idea.


The proper fix would be for security(8) not to process its files in 
incompatible modes, but there I can't contribute much beyond noise.

Re: openssl: s_time needs dns pledge promise

[Ricardo Mestre]

ok mestre@

On 19:07 Wed 01 Nov , Scott Cheloha wrote:
> Hi,
> 
> The following (and similar invocations) gets SIGABRT'd:
> 
>   openssl s_time -connect openbsd.org:443
> 
> BIO_set_conn_hostname(3), or whatever BIO_ctrl(3) is doing
> underneath, tries to resolve your target host and the process
> gets signaled when it enters socket(2).
> 
> Adding "dns" to the pledge(2) promise corrects this.
> 
> It looks like this has been broken since ~2015 but I have no
> release machines handy to confirm.
> 
> --
> Scott Cheloha
> 
> Index: usr.bin/openssl/s_time.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_time.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 s_time.c
> --- usr.bin/openssl/s_time.c  20 Jan 2017 08:57:12 -  1.17
> +++ usr.bin/openssl/s_time.c  1 Nov 2017 23:30:23 -
> @@ -254,7 +254,7 @@ s_time_main(int argc, char **argv)
>   int ver;
>  
>   if (single_execution) {
> - if (pledge("stdio rpath inet", NULL) == -1) {
> + if (pledge("stdio rpath inet dns", NULL) == -1) {
>   perror("pledge");
>   exit(1);
>   }
> 

openssl: s_time needs dns pledge promise

[Scott Cheloha]

Hi,

The following (and similar invocations) gets SIGABRT'd:

openssl s_time -connect openbsd.org:443

BIO_set_conn_hostname(3), or whatever BIO_ctrl(3) is doing
underneath, tries to resolve your target host and the process
gets signaled when it enters socket(2).

Adding "dns" to the pledge(2) promise corrects this.

It looks like this has been broken since ~2015 but I have no
release machines handy to confirm.

--
Scott Cheloha

Index: usr.bin/openssl/s_time.c
===
RCS file: /cvs/src/usr.bin/openssl/s_time.c,v
retrieving revision 1.17
diff -u -p -r1.17 s_time.c
--- usr.bin/openssl/s_time.c20 Jan 2017 08:57:12 -  1.17
+++ usr.bin/openssl/s_time.c1 Nov 2017 23:30:23 -
@@ -254,7 +254,7 @@ s_time_main(int argc, char **argv)
int ver;
 
if (single_execution) {
-   if (pledge("stdio rpath inet", NULL) == -1) {
+   if (pledge("stdio rpath inet dns", NULL) == -1) {
perror("pledge");
exit(1);
}

Re: crash on first boot after install and upgrade

[Martin Pieuchot]

On 01/11/17(Wed) 20:00, j...@posteo.de wrote:
> Hi,
> 
> after upgrading my x61 a got the following crash.
> Same happened after a fresh install on an APU2b4
> 
> I used a snapshot from the first of November (today).

Newer snapshot have it fixed.

crash on first boot after install and upgrade

[jes]

Hi,

after upgrading my x61 a got the following crash.
Same happened after a fresh install on an APU2b4

I used a snapshot from the first of November (today).

Installing: vmm-firmware
starting local daemons:uvm_fault(0x81b0eef8, 0x18, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  __mtx_enter:movl0(%rdi),%eax
ddb{2}> trace
__mtx_enter(18,81a6d888,fe00,fbb6,ff000988ee00,14) 
at _

_mtx_enter
task_add(0,14) at task_add+0x26
udp_input(2,81a721c0,0,11) at udp_input+0xf42
ip_deliver(8000220a9700,8000220a96b0,80019080,8119af20)
 at ip_deliver+0x1ed
ipintr() at ipintr+0x5a
if_netisr(80019080) at if_netisr+0x53
taskq_thread(0) at taskq_thread+0x67
end trace frame: 0x0, count: -6

ddb{2}> mach ddbcpu 1
Stopped at  x86_ipi_db+0x5: popq%rbp
ddb{1}> trace
x86_ipi_db(811fc983) at x86_ipi_db+0x5
x86_ipi_handler() at x86_ipi_handler+0x6b
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1f
--- interrupt ---
end of kernel
end trace frame: 0x99057405c75250cc, count: -3
0x41cb8c419c524153:

ddb{1}> mach ddbcpu 2
Stopped at  __mtx_enter:movl0(%rdi),%eax
ddb{2}> trace
__mtx_enter(18,81a6d888,fe00,fbb6,ff000988ee00,14) 
at _

_mtx_enter
task_add(0,14) at task_add+0x26
udp_input(2,81a721c0,0,11) at udp_input+0xf42
ip_deliver(8000220a9700,8000220a96b0,80019080,8119af20)
 at ip_deliver+0x1ed
ipintr() at ipintr+0x5a
if_netisr(80019080) at if_netisr+0x53
taskq_thread(0) at taskq_thread+0x67
end trace frame: 0x0, count: -6

ddb{2}> mach ddbcpu 3
Stopped at  x86_ipi_db+0x5: popq%rbp
ddb{3}> trace
x86_ipi_db(811fc983) at x86_ipi_db+0x5
x86_ipi_handler() at x86_ipi_handler+0x6b
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1f
--- interrupt ---
end of kernel
end trace frame: 0x99057405c75250cc, count: -3
0x41cb8c419c524153:

ddb{3}> ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
 92851  379194  65311  0  7 0x2mail.local
*86681  523918  65311  0  7 0x2mail.local
 20270   11827  69036  0  70x13sh
 11402  515714  1 99  30x100090  poll  sndiod
 31941  358896  1110  30x100090  poll  sndiod
 49166 799  65311 95  30x100092  kqreadsmtpd
 15703  167172  65311103  30x100092  kqreadsmtpd
 62632  193871  65311 95  30x100092  kqreadsmtpd
 18915  339309  65311 95  30x100092  kqreadsmtpd
 49822   96915  65311 95  30x100092  kqreadsmtpd
 58873  425139  65311 95  30x100092  kqreadsmtpd
 65311  109946  1  0  30x100080  kqreadsmtpd
 19328  507711  1  0  30x80  selectsshd
 71779  167550  78255 83  30x100092  poll  ntpd
 78255   38560   5892 83  30x100092  poll  ntpd
  5892  260951  1  0  30x100080  poll  ntpd
 82194  422873  17902 74  30x100092  bpf   pflogd
 17902  479204  1  0  30x80  netio pflogd
 86568   83772  59506 73  20x100090syslogd
 59506  504624  1  0  30x100082  netio syslogd
 67271  486051  1 77  30x100090  poll  dhclient
 98492  422766  1  0  30x80  poll  dhclient
 99776  430170  75634115  30x100092  kqreadslaacd
 81184  254836  75634115  30x100092  kqreadslaacd
 75634  290040  1  0  30x80  kqreadslaacd
 69036  209200  1  0  30x10008b  pause sh
 30781  214950  0  0  3 0x14200  pgzerozerothread
 60459   66822  0  0  3 0x14200  aiodoned  aiodoned
 60459   66822  0  0  3 0x14200  aiodoned  aiodoned
 86872  285309  0  0  3 0x14200  syncerupdate
 23737  172027  0  0  3 0x14200  cleaner   cleaner
  26168702  0  0  3 0x14200  reaperreaper
 19020  433159  0  0  3 0x14200  pgdaemon  pagedaemon
 21928  367938  0  0  3 0x14200  bored crynlk
  6734  265408  0  0  3 0x14200  bored crypto
 91366  468553  0  0  3 0x14200  bored sensors
 68799  445155  0  0  3 0x14200  mmctsksdmmc0
 61289  284181  0  0  3 0x14200  usbtskusbtask
  9550  293458  0  0  3 0x14200  usbatsk   usbatsk
 19379   33408  0  0  3  0x40014200  acpi0 acpi0
 77280  476645  0  0  3  0x40014200idle3
 90957  183445  0  0  3  0x40014200idle2
 47344  189253  0  0  3  0x40014200idle1
 95354  374982  0  0  7 0x14200softnet
 63605   78585  0  0  3 0x14200  bored systqmp
 62543  504034  0  0  

Re: bind commands in ENV file cause spurious warnings by security(8)

[Jeremie Courreges-Anglas]

On Wed, Nov 01 2017, Lari Rasku  wrote:
> Jeremie Courreges-Anglas kirjoitti 10/31/17 klo 16:23:
>> On Mon, Oct 30 2017, Lari Rasku  wrote:
>>> or how it might be worked around.
>>
>> case $- in *i*) ...;; esac
>>
>> See /etc/ksh.kshrc.
>
> Thanks, this spares me some irritation.
>
>> ENV is checked on purpose.  Whether it should use sh -i is another
>> question.
>
> Having plucked the courage to read the security source - if the goal is
> to inspect root's login environment, it would seem more straightforward
> to just run `ksh -lic 'echo PATH=$PATH; umask'` than to programmatically
> determine the files it sources and then analyze them individually.  But
> perhaps it's done this way for a reason.
>
> Another way to "fix" this issue would be just to remove the warnings in
> ksh.  Looking at the code, the "cannot bind, not a tty" print is
> controlled by a x_tty flag with no other purpose, set unconditionally in
> x_init_emacs():
>
>   $ cd /usr/src/bin/ksh; grep -C2 x_tty *.c
>   emacs.c-static int xlp_valid;
>   emacs.c-/* end from 4.9 edit.h } */
>   emacs.c:static int x_tty;  /* are we on a tty? */
>   emacs.c-static int x_bind_quiet;   /* be quiet when binding
>   keys */
>   emacs.c-static int (*x_last_command)(int);
>   --
>   emacs.c-   charin[LINE + 1];
>   emacs.c-
>   emacs.c:   if (x_tty == 0) {
>   emacs.c-   bi_errorf("cannot bind, not a tty");
>   emacs.c-   return (1);
>   --
>   emacs.c-x_init_emacs(void)
>   emacs.c-{
>   emacs.c:   x_tty = 1;
>   emacs.c-   ainit(AEDIT);
>   emacs.c-   x_nextcmd = -1;
>
> Where x_init_emacs() is called through x_init() if the shell is
> interactive.  This looks like vestigial code, since the kb_add()s in
> x_init_emacs() go through just fine whether a tty is attached or not.
>
> I can prepare a patch for this if desired.

Obviously x_init_emacs does more than than just set x_tty.  For example,
it touches kblist and AEDIT.  While bypassing x_tty may run fine now
because those variables are initialized to zero, I find this
non-obvious and fragile.  Testing x_tty means less questions.

And I think it's reasonable to process keybindings in interactive mode
only.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE