silence logging of dhcpd deny unknown-clients
Is there any way to silence these logs? I only want to hand out a small number of IPv4 addresses on my IPv6 network to those machines that won't function properly without them. That leaves many machines on my network constantly requesting IPv4 addresses, and dhcpd is clogging my /var/log/daemon file: > ... dhcpd[13399]: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via igc3 > ... dhcpd[13399]: no free leases on subnet 192.168.3.0 ... over and over and over again. I didn't see any logging options in dhcpd(8) or dhcpd.conf(5).
Re: Pine64 Quartz64 Model A -- Kernel hangs before installer
>From the dmesg you provided looks like installer is having problem enabling the sd card with sdmmc driver. I would recommend you disable and re-enable the sdmmc driver. To do the first boot from sd card that hit ctl+c before the installer bootstrap the kernal for installation. No enter the following commands boot -c disable sdmmc boot -c enable sdmmc for more information check openbsd boot_config man page Patcher > On Tuesday, 26. March 2024 5:13, Dallin Dahl > [/webmail/send?to=dallinjd...@gmail.com] wrote: > > > I'm attempting to install openbsd 7.4 on the above-mentioned board. I've > tried both the miniroot and install images with the same process and the same > outcome. Here is how I prepared the install sd card: > > > doas dd if=miniroot74.img of=/dev/mmcblk0 bs=1M > doas mount /dev/mmcblk0p1 /mnt > doas mkdir /mnt/vendor > doas cp rk3566-quartz64-a.dtb /mnt/vendor/ > doas umount /mnt > doas dd if=idbloader.img of=/dev/mmcblk0 seek=64 > doas dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 > > > When I boot the board, I get lots of messages about things that aren't > configured, but that seems normal. It seems to proceed normally, but hangs > after the following lines in the log: > > > dwpcie0: can't initialize hardware > scsibus0 at sdmmc0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: removable > sd0: 121909MB, 512 bytes/sector, 249670656 sectors > sdmmc1: can't enable card > sdmmc2: can't enable card > umass0 at uhub1 port 1 configuration 1 interface 0 " USB DISK 3.0" rev > 2.10/1.10 addr 2 > umass0: using SCSI over Bulk-Only > scsibus1 at umass0: 2 targets, initiator 0 > sd1 at scsibus1 targ 1 lun 0: <, USB DISK 3.0, PMAP> removable > serial.13fe55005B4C06311B98 > sd1: 59064MB, 512 bytes/sector, 120963072 sectors > softraid0 at root > scsibus2 at softraid0: 256 targets > root on rd0a swap on rd0b dump on rd0b > WARNING: bad clock chip time > WARNING: CHECK AND RESET THE DATE! > cpu0: regulator not implemented > > > I do get the boot prompt, but never the installation prompt. I copied the > dtb, itb and idbloader files from a manjaro image provided for the board. I > don't know if that's the proper way to do things, but saw it mentioned on > several forums. I'm not sure where to go from here. > > > Thanks! > --Dallin
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
Replying now to cho...@jtan.com: >[…] any >application which uses the X server (ie. can access the tcp port >or unix socket and has the correct xauth key […] The default PF configuration blocks access to the ports, but only on non-loopback interfaces. https://github.com/openbsd/src/blob/master/etc/pf.conf Again, I'm not an X11 expert, but it looks like the X auth file exists because anyone can connect to these ports on localhost, so the file would mediate it further. PF can match packets based on UIDs, but if I understand pf.conf(5) correctly, it matches based on the user owning the listening socket (which would be the dedicated X11 account) rather than the user that tries to connect to the X server. The xauth(1) and Xsecurity(7) man pages seem relevant, I'll have a deeper look at them later.
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
(Note for everyone: This message is intended to shame a troll; if you're here to follow the technical discussion only, feel free to skip reading this message.) ~ | ~ | ~ | ~ | ~ | ~ On Friday, March 29, 2024, Jan Stary wrote: > > > > (The person > > > > you're replying to should be in the To field, and the mailing list > in the > > > > Cc field.) > > > > > > I replied to the list. > > > If you are not subscribed to the list, > > > you don't get the list replies. > > > > I did not know that. > > Please don't send anything else to this mailing list. Shut up. That's warranted given that this is essentially what you're telling me here (also more explicitly in the last part of your message, as quoted at the bottom here). > > > > Repeat after me: I can display what looks like a login screen; > > > I don't to have anything to do with ctrl-alt-del to display that. > > > > I do not need to repeat mantras. I did not deny that programs can do > that, > > quite the opposite: I explicitly acknowledged that programs can do that, > > and asked what mechanism OpenBSD provides to ensure, at the user's > request, > > that the operating system temporarily takes over with a real login prompt > > that cannot be interfered with or snooped on. > > OpenBSD provides no "mechanism" to make it impossible for a user > to display something that looks like a login screen; just like > no other OS provides no such mechanism. Once again, that's the opposite of what I said, and completely missing what I said. > > > I've looked at the > > source code and issue tracker of upstream Firefox in the past and it has > > upstream support for pledge(2) and unveil(2). > > Great, you figured it out: if you want to know if a given piece of > software uses pledge, grep its source code for pledge. Sounds very tiresome and cumbersome to check. You failed to point at any rule according to which I'm not permitted to ask a general question about such software without resorting to tiresome and cumbersome manual methods like what you're suggesting here, and you consistently ignore this by bringing the same manual grep/find suggestion again and again with no sensible reason given what I explained now. > > > Your "if there is one [program I care about]", "duh", and other things > > you've said so far to me and I haven't pointed out in this paragraph show > > that you're very disrespectful towards me. > > Nothing gets past you. False. I strive to exercise critical thinking, analytical thinking, and logic as much as possible. Nonsense, however, doesn't "get past me", as I rightfully evaluate it as nonsense and therefore dismiss it. Ditto regarding true but irrelevant things. > > > I saw that I got replied to using marc.info, > > No you didn't. Maybe you'll understand it better if I'll rephrase, because you're definitely lying here, with no basis: I saw, using marc.info, that I got replied to. > > > and proceeded to log into my > > email to reply, but then I didn't see that reply in my inbox. So I looked > > at an old thread I had a few years ago on this mailing list that I knew > > that worked well, and looked at the To and Cc fields in the exchange of > > messages, and I assumed this is how it's always meant to be. > > You assumed wrong. Correct; I assumed you made a honest mistake. I had no better way to know what's true, however, so it's not really my fault, because I acted in a good way within the limits of my then-current knowledge and range of possible reactions I could react in the situation. > > > this isn't my first time using a mailing list, > > but I'm pretty sure it's my second time, and I'm fairly new > > to how mailing lists work. I deserve none of your disrespectful attitude > > and your wrong assumption of ill intentions from me; furthermore, you > > completely ignored the substance of the discussion in this thread, and > did > > not contribute anything useful to the discussion. Your entire reply was > > meant to purposely be rude to me and attack me ad hominem. Take an > example > > from Luke (luke...@onemodel.org), they actually contributed something > > meaningful to the discussion and didn't act like an asshole to me. I > > recognize your name, I know you publish lots of material about OpenBSD, > for > > example the links in your signature, and you're also part of the > editorial > > team of undeadly.org, which I frequently visit. It's a shame you're > such an > > asshole, though. Disgusting. > > Right, everybody knows PNH is a disgusting asshole contributing nothing. Peter N. M. Hansteen's disgusting behavior has absolutely nothing to do with any contribution he may or may not have contributed whatsoever. Furthermore, I said quite the opposite: I mentioned how he's part of the OpenBSD news website that I love to visit and that I've seen his name in many places (for example, I found his networking tutorials in the past, and saved the links for myself because it's good learning material and interesting). I explicit
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
Luke A. Call writes: > > On 2024-03-29 09:01:07-0400, James Huddle wrote: > > Exfiltrator. There's an 11-letter word that starts with "ex". X11. > > After a quick web search, I'm not sure I follow. Is that a reference to > a program that exfiltrates data after a computer is compromised? Can you > elaborate a little? I realize this is an ignorant question. In short, there is a well known shortcoming or feature depending on who you ask inherent in the X protocol's design where any application which uses the X server (ie. can access the tcp port or unix socket and has the correct xauth key, which is to say all of them) can request (and get) the ability to read all of the X events, which includes every key press and mouse movement in every application. Exfiltrator is 11 letters and we are at X protocol version 11. There are common mitigations against this problem, such as not giving strangers the ability to run unknown programs on your console. Matthew
Re: No coloring with colorls
What should I put in /etc/ttys, taking into account that I regularly use multiple virtual consoles? And where in that file do I place that? At the beginning or the end? Or somewhere in between? Op 29-03-2024 om 09:15 schreef Stuart Henderson: On 2024-03-28, Karel Lucas wrote: Op 28-03-2024 om 07:51 schreef Stuart Henderson: For the console, use /etc/ttys. For an X terminal, use whatever mechanism is correct for that terminal (.Xdefaults XTerm*termName for xterm). The file /etc/ttys is 22.5kB in size and is full of all kinds of "tty** ...". I don't think this is the right file to use something like that. It seems to me that you are making the system disrupted/unstable by doing so. Those "ttys**..." won't vouch for it for nothing. Yes that is exactly the right file. That is what the file is *for*. It sets the console type for various ways of accessing consoles on the system. The "console" and "ttyC*" lines are the ones you want (the additional ones are for various virtual consoles on ctrl-alt-f2, etc). (The "tty0*" are for serial consoles if you have them.)
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
On 2024-03-29 09:01:07-0400, James Huddle wrote: > Exfiltrator. There's an 11-letter word that starts with "ex". X11. After a quick web search, I'm not sure I follow. Is that a reference to a program that exfiltrates data after a computer is compromised? Can you elaborate a little? I realize this is an ignorant question. > On Thu, Mar 28, 2024 at 7:39???PM Luke A. Call wrote: > > > On 2024-03-28 17:28:56+0100, Jan Stary wrote: > > > > (2) I've learned that X11 allows locally running malware to sniff the > > > > keystrokes input to any other X11-using app running under any user. > > > > > > I don't believe that's true. > > > Where have you "learned" that, and how does that work? > > > "Dear X11, what is $user typing into his firefox textarea"? > > > > I'm no X expert, but I think what you are saying is technically correct > > across users, but I believe it is possible for one application to > > sniff the keystrokes input to another app running under the *same* user, at > > least, and under different users in the same X session depending on how > > they connect. Specifically: > > > > 1) Under `man xterm' in the "SECURITY" section it says some related > > things that sound like that is what they are saying. I can't elaborate > > on what it says there but that made me want to be cautious. > > > > 2) running > >xinput list > > ...shows some devices, where on my system the /dev/wskbd has "id=6". > > Then taking that number 6 and doing > >xinput test 6 > > ...and typing in a separate xterm window shows the keystrokes from the > > second window, in the first. I believe the same would be true for any > > X application running as the *same* user. > > > > 3) I did some experimenting in the past with "ssh -X user@..." and > > "ssh -Y user@...", and only when using -Y were keystrokes visible across > > users. Similar things can be done with less cpu overhead using xauth > > and magic cookies etc (I played with that, with help from people on this > > list, scripted it for myself using what they and man pages helped me > > learn, and haven't > > thought about it much since then, except to use the scripts--but it is very > > handy for me to have things running as different users within the same X > > session, because of these boundaries around keyboard sniffing and also > > filesystem etc restrictions across users). > > > > 4) I am under the impression that the clipboard sharing between X users is > > not restricted as the above things are. Ie, one can spy on another > > freely. > > > > Luke Call > > > >
Re: How to exit cu?
On Fri, 29 Mar 2024 12:35:18 +0800, Sadeep Madurange wrote: > I managed to get it working. I needed to press Enter, press ~ (and > release), then press Ctrl and D keys at the same time. Thank you. This is because the tilde escapes only work on the first character of a line. The same is true of ssh. - todd
Re: How to exit cu?
I just don't even learn to know what cu is. It's fantastic, everything works great. On Fri, Mar 29, 2024 at 5:02 PM Florian Obser wrote: > > On 2024-03-29 08:12 +01, Evan Sherwood wrote: > > Before I learned about the tilde sequences, I just unplugged the USB > > adapter. That quits cu. > > > > Worked in my case since my device was under its own power. FYI. > > > > That's neat, I always just reboot :D Same for quitting vi... > > -- > In my defence, I have been left unsupervised. >
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
Exfiltrator. There's an 11-letter word that starts with "ex". X11. On Thu, Mar 28, 2024 at 7:39 PM Luke A. Call wrote: > On 2024-03-28 17:28:56+0100, Jan Stary wrote: > > > (2) I've learned that X11 allows locally running malware to sniff the > > > keystrokes input to any other X11-using app running under any user. > > > > I don't believe that's true. > > Where have you "learned" that, and how does that work? > > "Dear X11, what is $user typing into his firefox textarea"? > > I'm no X expert, but I think what you are saying is technically correct > across users, but I believe it is possible for one application to > sniff the keystrokes input to another app running under the *same* user, at > least, and under different users in the same X session depending on how > they connect. Specifically: > > 1) Under `man xterm' in the "SECURITY" section it says some related > things that sound like that is what they are saying. I can't elaborate > on what it says there but that made me want to be cautious. > > 2) running >xinput list > ...shows some devices, where on my system the /dev/wskbd has "id=6". > Then taking that number 6 and doing >xinput test 6 > ...and typing in a separate xterm window shows the keystrokes from the > second window, in the first. I believe the same would be true for any > X application running as the *same* user. > > 3) I did some experimenting in the past with "ssh -X user@..." and > "ssh -Y user@...", and only when using -Y were keystrokes visible across > users. Similar things can be done with less cpu overhead using xauth > and magic cookies etc (I played with that, with help from people on this > list, scripted it for myself using what they and man pages helped me > learn, and haven't > thought about it much since then, except to use the scripts--but it is very > handy for me to have things running as different users within the same X > session, because of these boundaries around keyboard sniffing and also > filesystem etc restrictions across users). > > 4) I am under the impression that the clipboard sharing between X users is > not restricted as the above things are. Ie, one can spy on another > freely. > > Luke Call > >
Re: How to exit cu?
FWIW I've seen the same behavior, glad you figured it out. 73 diana On March 28, 2024 10:35:18 PM MDT, Sadeep Madurange wrote: >On 2024-03-29 14:56:08, jslee wrote: >> On Fri, 29 Mar 2024, at 14:18, Sadeep Madurange wrote: >> > I opened a serial terminal using 'cu -l cuaU0 -s 115200', but can't >> > exit >> >> Enter >> ~ >> . >> >> Try that >> >> (It also works for OpenSSH interactive sessions) > >I managed to get it working. I needed to press Enter, press ~ (and >release), then press Ctrl and D keys at the same time. Thank you. > >-- >Sadeep Madurange >PGP: 103BF9E3E750BF7E >
Re: How to exit cu?
On 2024-03-29 08:12 +01, Evan Sherwood wrote: > Before I learned about the tilde sequences, I just unplugged the USB > adapter. That quits cu. > > Worked in my case since my device was under its own power. FYI. > That's neat, I always just reboot :D Same for quitting vi... -- In my defence, I have been left unsupervised.
Re: No coloring with colorls
On 2024-03-28, Karel Lucas wrote: > > > Op 28-03-2024 om 07:51 schreef Stuart Henderson: >> For the console, use /etc/ttys. >> >> For an X terminal, use whatever mechanism is correct for that terminal >> (.Xdefaults XTerm*termName for xterm). > > The file /etc/ttys is 22.5kB in size and is full of all kinds of "tty** > ...". I don't think this is the right file to use something like that. > It seems to me that you are making the system disrupted/unstable by > doing so. Those "ttys**..." won't vouch for it for nothing. Yes that is exactly the right file. That is what the file is *for*. It sets the console type for various ways of accessing consoles on the system. The "console" and "ttyC*" lines are the ones you want (the additional ones are for various virtual consoles on ctrl-alt-f2, etc). (The "tty0*" are for serial consoles if you have them.) -- Please keep replies on the mailing list.
Re: Dell PERC H745
On 28/03/2024 20:17, Stuart Henderson wrote: > On 2024-03-28, Hrvoje Popovski wrote: >> On 28.3.2024. 11:01, Kapetanakis Giannis wrote: >>> I'm looking for a new server to replace our firewall/routing. >>> >>> Would like to ask if PERC H745 is supported. >>> >>> mfi(4) lists >>> - Dell PERC 5/e, PERC 5/i, PERC 6/e, PERC 6/i, PERC H310, PERC >>> H700, PERC H800 >>> >>> Is this ok? >>> >>> Trying bsd.rd on a newer server with H755, it was NOT detected. >>> On Linux it is shown as >>> 65:00.0 RAID bus controller: Broadcom / LSI MegaRAID 12GSAS/PCIe Secure >>> SAS39xx >>> DeviceName: SL3 RAID >>> Subsystem: Dell PERC H755 Front >>> >>> That is on 7.4, didn't try current. >>> >>> However the BOSS-S1 adapter with 2 x M.2 sticks was detected >>> >>> How about HBA330 Mini and/or PERC H730P Mini ? >>> >>> About CPUs, I'm between Intel Xeon Gold 5315Y @ 3.20GHz vs AMD EPYC 72F3 >>> Both are 8 cores, I will put 2 x cpus. Haven't tried EPYC at all but looks >>> more performant. >>> >>> G >>> >> Hi, >> >> don't go with BOSS adapter or HBA330. I have both adapters in lab and >> they just don't work. >> I have working OpenBSD on PERC H740p, PERC H740P Mini, PERC H330 mini, >> PERC H310 Mini. I can't remember but I think that H730p should work. > also working: PERC H710 Mini, PERC H755 Front (both mfii) Thanks Hrvoje and Stuart all for the valuable info. There are so many adapters given/updated by Dell every year, maybe we should update the man pages to add the working ones? My BOSS-S1 Modular adapter is detected both on 7.4 and current. PERC H755 Front is indeed also detected with current. I'm sure it was not with 7.4 when I tried yesterday. This is today dmesg with current (20 Mar) from R650xs: OpenBSD 7.5 (RAMDISK_CD) #76: Wed Mar 20 15:53:54 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 136804360192 (130466MB) avail mem = 132653326336 (126508MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x69534000 (65 entries) bios0: vendor Dell Inc. version "1.12.1" date 09/13/2023 bios0: Dell Inc. PowerEdge R650xs acpi0 at bios0: ACPI 6.2 ahci2 at pci1 dev 0 function 0 "Marvell 88SE9230 AHCI" rev 0x11: msi, AHCI 1.2 ahci2: port 0: 6.0Gb/s ahci2: port 2: 1.5Gb/s scsibus2 at ahci2: 32 targets ahci2: stopping the port, softreset slot 31 was still active. ahci2: failed to stop port, cannot softreset ahci2: failed to stop port, cannot softreset ahci2: failed to stop port, cannot softreset sd0 at scsibus2 targ 0 lun 0: t10.ATA_DELLBOSS_VD_c2d0e37927240010_ sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin ahci2: stopping the port, softreset slot 31 was still active. ahci2: failed to stop port, cannot softreset mfii0 at pci10 dev 0 function 0 "Symbios Logic MegaRAID SAS39XX" rev 0x00: msi mfii0: "PERC H755 Front", firmware 52.26.0-5179, 8192MB cache scsibus3 at mfii0: 240 targets sd1 at scsibus3 targ 239 lun 0: naa.6f4ee0806477b5002d04b844d6503c0e sd1: 2288640MB, 512 bytes/sector, 4687134720 sectors scsibus4 at mfii0: 256 targets sd0> p OpenBSD area: 0-937571968; size: 937571968; free: 3712 #size offset fstype [fsize bsize cpg] c:9375719680 unused i: 2097152 2048 ext2fs j:935471104 2099200 unknown sd0> l # /dev/rsd0c: type: SCSI disk: SCSI disk label: DELLBOSS VD duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 58361 total sectors: 937571968 boundstart: 0 boundend: 937571968 sd1> p OpenBSD area: 64-4294961685; size: 4294961621; free: 4294961621 #size offset fstype [fsize bsize cpg] c: 46871347200 unused sd1> l # /dev/rsd1c: type: SCSI disk: SCSI disk label: PERC H755 Front duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 291760 total sectors: 4687134720 boundstart: 64 boundend: 4294961685 G
Re: How to exit cu?
Before I learned about the tilde sequences, I just unplugged the USB adapter. That quits cu. Worked in my case since my device was under its own power. FYI.
