Re: iwm wifi driver errors
On Sun, Mar 15, 2020 at 02:15:36PM +, b...@0x1bi.net wrote: > Have you installed the wireless firmware? > http://firmware.openbsd.org/firmware/ > yeah of course without the firmware the interface doesn't work, and now I'm using the wifi.
iwm wifi driver errors
Hi, I found the following error in the logs about the wifi driver iwm: iwm0: could not remove binding (error 35) iwm0: fatal firmware error iwm0: could not remove binding (error 35) iwm0: could not remove binding (error 35) iwm0: failed to update MAC iwm0: could not add MAC context (error 35) iwm0: could not abort background scan iwm0: could not remove STA (error 35) iwm0: could not remove STA (error 35) iwm0: could not update PHY context (error 35) iwm0: could not add binding (error 35) iwm0: fatal firmware error Anyone knows what means ? thanks
Re: Hardening browser
On Thu, Mar 05, 2020 at 07:32:36AM -0700, Luke A. Call wrote: > On 03-05 04:18, Tomasz Rola wrote: > > On Wed, Mar 04, 2020 at 02:06:40AM +0100, whistlez...@riseup.net wrote: > > > Hi, > > > in the following message: > > > https://marc.info/?l=openbsd-misc=158110613210895=2 > > > Theo discourages to use unveil instead of chroot. > > > I asked if he suggests the same for the browser but he asked that chroot > > > is onlye for *root*. > > > Then what should I do to hardening the most exposed piece of code that > > > we use everyday ? > > > Now I'm using unveil+chrome... > > > Thank you. > > [] > > As of me, I use the trick with multiple users for different roles > > (similar to other person who posted in this thread). I also employ > > noscript in some of the roles. > > I just leave javascript off for usual browsing, with a tab sitting open > in chromium or iridium to turn it on for the occasional temporary need, > or added to the browser's exception list to allow permanently for > certain sites. This partly because it seems easy, and partly since I > probably won't know if a browser extension is sold to a malicious entity, or > otherwise compromised (so, seems a smaller attack surface, but still usually > convenient.) As I know many sites without js doesn't work. Anyway I don't understand how switching off js defend you from 0day browser bug. Maybe you mean that because many 0day concern javascript ?
Re: Hardening browser
On Wed, Mar 04, 2020 at 03:28:35PM +, Kevin Chadwick wrote: > On 2020-03-04 11:38, Ottavio Caruso wrote: > > Probably not what you were looking for but, back in the days when I > > was ultra paranoid about my web browsing, I used to use stripped down > > live usb installations of Linux distros (DSL was one of them that I > > remember). I ignore if OpenBSD comes with such a solution out the box, > > but I'm sure it wouldn't be difficult to make your own read-only > > install. Then, you could either reboot from it or run it through an > > emulator. > > A live cd is read-only and is also something I did for a while in my teenage > years. Knoppix, Insert were examples and STD was another aptly named one as it a read only cd don't give you any defense againt uefi rootkit > > However, considering OpenBSD replaces it's whole base every upgrade with > signed > binaries, then you get all of that for free. You can even double check the > bios > with flashrom (less so on laptops), bootloader, signing keys, packages etc., > if > you want to. > if your kernel is infected with uefi rootkit most probably double check uefi or bios with flashrom is absolutely not useful. > If this effort is really worth it, then it probably makes more sense than > trusting someone else to package up a usb linux distro or CD. > the problem is not trusting people that make package, the problem is the sites you visit.
Re: Hardening browser
On Wed, Mar 04, 2020 at 11:38:40AM +, Ottavio Caruso wrote: > On Wed, 4 Mar 2020 at 01:06, wrote: > > > > Hi, > > in the following message: > > https://marc.info/?l=openbsd-misc=158110613210895=2 > > Theo discourages to use unveil instead of chroot. > > I asked if he suggests the same for the browser but he asked that chroot > > Probably not what you were looking for but, back in the days when I > was ultra paranoid about my web browsing, I used to use stripped down > live usb installations of Linux distros (DSL was one of them that I > remember). I ignore if OpenBSD comes with such a solution out the box, > but I'm sure it wouldn't be difficult to make your own read-only > install. Then, you could either reboot from it or run it through an > emulator. > My opinion is that in the last 10 years the world of hackers groups was deeply changed. Deface or big worms that make big damages are not in fashion anymore. Today the hackers group want just only be as hidden as they can. Then today the biggest problems are the uefi/bios malware, if you use a read only live cd or usb don't stop someone infect your firmwares. And when you reboot your machine you are hacked. Maybe with an hypervisor that can isolate processes and kernels the job is more hard. One of the biggest criticism I make to openbsd is that the everyone processes are visible to everyone. So that if you use muliple account for multiple application you don't stop an infected process to see if you run a browser, a irc session and maybe what network you are connected, if you opened pdf, if you used vim for code and what code and so on. And the last but first for importance if you are sniffing your traffic to search a covert channel. If my browser is infected with a malware the first thing I do is try to sniff the traffic to detect strange destinations, but if the infected process can see if I'm running a sniffer all my investigations are absolutely unuseful. If a very skilled hacker exploit your browser, take the root and infect your uefi, you must trash your laptop. And of course if you discover it, because if someone infect your uefi most problably you will never know it!
Hardening browser
Hi, in the following message: https://marc.info/?l=openbsd-misc=158110613210895=2 Theo discourages to use unveil instead of chroot. I asked if he suggests the same for the browser but he asked that chroot is onlye for *root*. Then what should I do to hardening the most exposed piece of code that we use everyday ? Now I'm using unveil+chrome... Thank you.
6.6, X and braswell
Hi, I have the following bug: https://marc.info/?t=15636262941=1=2 now I'm on 6.5 and it works, but maybe one month ago I tried to install 6.6 and I found the bug. Anyone know if it was been resolved ? Thanks Whistlez
ffs details
Hi, I need some details about ffs, I read the kernel source but my c knowledge is very basic. I understood all about the superblock but my problem is understand how the files are allocated on the disk. Anyone could give me more details about files allocation ? Thank you.
Re: strange dmesg
On Mon, Feb 10, 2020 at 09:45:06AM -, Stuart Henderson wrote: > On 2020-02-10, Janne Johansson wrote: > > Den lör 8 feb. 2020 kl 11:31 skrev : > > > >> Hi, > >> I have some strange output from dmesg, what could be ? > >> At the follwoing link I've posted some screenshots: > >> https://postimg.cc/gallery/1o4wsaw74/ > >> > > > > dmesg is contained in a memory buffer with (hopefully) room for more than > > one dmesg, so you can get > > previous versions listed when you run it. If the memory gets slightly > > corrupted during reboots, > > I guess the "other" dmesgs can come out as garbage, based on how memory > > gets reused or > > reallocated in the time between reboot and next boot when the OS isn't in > > control of the > > RAM. > > From the contents, this one looks like it was probably overwritten with > some UEFI code during boot. > Could be a UEFI rootkit ? Or something that from UEFI try to inject code in the kernel ?
strange dmesg
Hi, I have some strange output from dmesg, what could be ? At the follwoing link I've posted some screenshots: https://postimg.cc/gallery/1o4wsaw74/ Thank you
Re: chroot vs unveil
On Thu, Feb 06, 2020 at 10:35:17AM -0700, Theo de Raadt wrote: > Kevin Chadwick wrote: > > > I am considering replacing all chroot use with unveil in my processes even > > where > > no filesystem access is required. > > I am discouraging this. > > unveil is a complicated mechanism, and we may still discover a bug in > it. > > Almost all the chroot in the tree are to empty unwriteable directories, > in which case chroot is very secure and a very simple mechanism. > you'd suggest the same for the browsers ? thank you
