Podcasts about nvram

In the security news this week: You should really just patch things, the NVD backlog, Android phones with malware pre-installed, so convenient, keyloggers and a creepy pharmacist, snooping on federal workers, someone stole your browser history, NSA director fired, deputy director of NSA also fired, CrushFTP the saga continues, only steal the valid credit cards, another post that vanished from the Internet, hiding in NVRAM, protecting the Linux kernel, you down with MCP?, more EOL IoT, bypassing kernel protections, when are you ready for a pen test, red team and bug bounty, what EDR is really missing, and based on this story you should just patch everything all the time! Visit https://www.securityweekly.com/psw for all the latest episodes! Show Notes: https://securityweekly.com/psw-869

In the security news this week: You should really just patch things, the NVD backlog, Android phones with malware pre-installed, so convenient, keyloggers and a creepy pharmacist, snooping on federal workers, someone stole your browser history, NSA director fired, deputy director of NSA also fired, CrushFTP the saga continues, only steal the valid credit cards, another post that vanished from the Internet, hiding in NVRAM, protecting the Linux kernel, you down with MCP?, more EOL IoT, bypassing kernel protections, when are you ready for a pen test, red team and bug bounty, what EDR is really missing, and based on this story you should just patch everything all the time! Show Notes: https://securityweekly.com/psw-869

In the security news this week: You should really just patch things, the NVD backlog, Android phones with malware pre-installed, so convenient, keyloggers and a creepy pharmacist, snooping on federal workers, someone stole your browser history, NSA director fired, deputy director of NSA also fired, CrushFTP the saga continues, only steal the valid credit cards, another post that vanished from the Internet, hiding in NVRAM, protecting the Linux kernel, you down with MCP?, more EOL IoT, bypassing kernel protections, when are you ready for a pen test, red team and bug bounty, what EDR is really missing, and based on this story you should just patch everything all the time! Visit https://www.securityweekly.com/psw for all the latest episodes! Show Notes: https://securityweekly.com/psw-869

In the security news this week: You should really just patch things, the NVD backlog, Android phones with malware pre-installed, so convenient, keyloggers and a creepy pharmacist, snooping on federal workers, someone stole your browser history, NSA director fired, deputy director of NSA also fired, CrushFTP the saga continues, only steal the valid credit cards, another post that vanished from the Internet, hiding in NVRAM, protecting the Linux kernel, you down with MCP?, more EOL IoT, bypassing kernel protections, when are you ready for a pen test, red team and bug bounty, what EDR is really missing, and based on this story you should just patch everything all the time! Show Notes: https://securityweekly.com/psw-869

Synopis I installed a new 1TB Crucial MX500 SSD into my work computer. While we are mostly a Windows based business, as the IT guy I do get a bit of discretion when updating my own machine (i.e. I get to solve all the problems I create). Last year, I decided to run the Pop!_OS distribution of Linux on my work computer and run Windows in a VM on it. Recently the Windows image had grown and was causing disk space notifications. This prompted the additional hard drive. During the initial installation of Pop!_OS, I remember deciding not to bother with installing Linux Volume Management (LVM). I have used it in the past, but I am still much more comfortable with the old style device mapping and mounting disk partitions to directories. I even rationalized that if I needed to add more space, I will just add a new disk with one big partition and map it to the home directory. Now a year later I am adding a new HD and thinking, I really hate all the space that is most likely going to be wasted once I move the Windows image to the new drive. Ok, I guess I should figure out how to install LVM, and use it to manage the space on both drives. Luckily there a number of good blogs to be found on adding LVM to an existing system. The following are the steps and commands I used to accomplish my goal. Commands Most of the following commands need to be run as root. I decided to change to root user instead of typing sudo before every command. The basic steps to creating a single filesystem sharing the storage space between two physical disk partitions are: Let LVM know about the new disk. In my case, create a volume group and add the new disk and its full storage space to it. Copy the disk partition with the root filesystem from the origin disk to the new volume group Expand the root filesystem on the volume group to the full size of the volume group. Update system configuration to boot with the root filesystem on the new volume group. Let LVM know about the old root disk partition. Add the old root partition to the volume group. Expand the root filesystem on the volume group to include the new space in the volume group. root@work# pvcreate /dev/sdb root@work# pvdisplay "/dev/sdb" is a new physical volume of "931.51 GiB" --- NEW Physical volume --- PV Name /dev/sdb VG Name PV Size 931.51 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID wRBz38-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx root@work# vgcreate workvg /dev/dsb No device found for /dev/dsb. root@work# vgcreate workvg /dev/sdb Volume group "workvg" successfully created root@work# vgdisplay --- Volume group --- VG Name workvg System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 931.51 GiB PE Size 4.00 MiB Total PE 238467 Alloc PE / Size 0 / 0 Free PE / Size 238467 / 931.51 GiB VG UUID 67DSwP-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx root@work# pvdisplay --- Physical volume --- PV Name /dev/sdb VG Name workvg PV Size 931.51 GiB / not usable 1.71 MiB Allocatable yes PE Size 4.00 MiB Total PE 238467 Free PE 238467 Allocated PE 0 PV UUID wRBz38-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx root@work# lvcreate -n root -L 931.51 workvg Rounding up size to full physical extent 932.00 MiB Logical volume "root" created. root@work# cat /dev/sda3 >/dev/mapper/workvg-root cat: write error: No space left on device Hmmm why can't it copy the smaller disk onto a larger one? root@work# pvdisplay --- Physical volume --- PV Name /dev/sdb VG Name workvg PV Size 931.51 GiB / not usable 1.71 MiB Allocatable yes PE Size 4.00 MiB Total PE 238467 Free PE 238234 Allocated PE 233 PV UUID wRBz38-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx root@work# lvdisplay --- Logical volume --- LV Path /dev/workvg/root LV Name root VG Name workvg LV UUID srXpUd-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx LV Write Access read/write LV Creation host, time work.example.com, 2022-10-18 08:46:34 -0400 LV Status available # open 0 LV Size 932.00 MiB Current LE 233 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1 Whoops, the default unit for the lvcreate is MB, and I forgot to add G to my size. A good reason to always include units in whatever you do :) Also, pay attention to any reports printed at the end of a successful command. When I scrolled back I realized it told me the size it created. root@work# lvextend -l +100%FREE /dev/workvg/root Size of logical volume workvg/root changed from 932.00 MiB (233 extents) to 931.51 GiB (238467 extents). Logical volume workvg/root successfully resized. root@work# lvdisplay --- Logical volume --- LV Path /dev/workvg/root LV Name root VG Name workvg LV UUID srXpUd-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx LV Write Access read/write LV Creation host, time work.example.com, 2022-10-18 08:46:34 -0400 LV Status available # open 0 LV Size 931.51 GiB Current LE 238467 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1 root@work# cat /dev/sda3 >/dev/mapper/workvg-root root@work# mkdir /media/new-root root@work# mount /dev/mapper/workvg-root /media/new-root root@work# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda3 450G 421G 5.6G 99% / /dev/sda1 497M 373M 125M 76% /boot/efi /dev/sda2 4.0G 3.4G 692M 84% /recovery /dev/mapper/workvg-root 450G 421G 5.7G 99% /media/new-root Ok, the LV volume is resized but the filesystem now needs to expanded to use the new disk space root@work# umount /media/new-root/ root@work# resize2fs /dev/mapper/workvg-root resize2fs 1.46.5 (30-Dec-2021) Please run 'e2fsck -f /dev/mapper/workvg-root' first. root@work# e2fsck -f /dev/mapper/workvg-root e2fsck 1.46.5 (30-Dec-2021) Pass 1: Checking inodes, blocks, and sizes Inode 7210086 extent tree (at level 2) could be narrower. Optimize? yes Pass 1E: Optimizing extent trees Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/mapper/workvg-root: ***** FILE SYSTEM WAS MODIFIED ***** /dev/mapper/workvg-root: 827287/29974528 files (1.2% non-contiguous), 112395524/119870981 blocks root@work# resize2fs /dev/mapper/workvg-root resize2fs 1.46.5 (30-Dec-2021) Resizing the filesystem on /dev/mapper/workvg-root to 244190208 (4k) blocks. The filesystem on /dev/mapper/workvg-root is now 244190208 (4k) blocks long. root@work# mount /dev/mapper/workvg-root /media/new-root root@work# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda3 450G 421G 5.5G 99% / /dev/mapper/workvg-root 916G 421G 449G 49% /media/new-root Much better. Now we need to get the computer to boot using LVM and the new drive. Need to make sure /etc/fstab is updated to point to the new root filesystem. Make some in-memory filesystems available under the new root: root@work# mount --rbind /dev /media/new-root/dev root@work# mount --bind /proc /media/new-root/proc root@work# mount --bind /sys /media/new-root/sys root@work# mount --bind /run /media/new-root/run root@work# chroot /media/new-root root@work# cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # PARTUUID=949a09f0-xxxx-xxxx-xxxx-xxxxxxxxxxxx /boot/efi vfat umask=0077 0 0 PARTUUID=bbcc2068-xxxx-xxxx-xxxx-xxxxxxxxxxxx /recovery vfat umask=0077 0 0 UUID=9f1f68bb-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 noatime,errors=remount-ro 0 0 /dev/mapper/cryptswap none swap defaults 0 0 root@work# vi /etc/fstab root@work# cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # PARTUUID=949a09f0-xxxx-xxxx-xxxx-xxxxxxxxxxxx /boot/efi vfat umask=0077 0 0 PARTUUID=bbcc2068-xxxx-xxxx-xxxx-xxxxxxxxxxxx /recovery vfat umask=0077 0 0 /dev/mapper/workvg-root / ext4 noatime,errors=remount-ro 0 0 /dev/mapper/cryptswap none swap defaults 0 0 root@it05:/media/new-root/etc/initramfs-tools# lsinitramfs /boot/initrd.img-$(uname -r) | grep lvm etc/lvm etc/lvm/lvm.conf etc/lvm/lvmlocal.conf etc/lvm/profile etc/lvm/profile/cache-mq.profile etc/lvm/profile/cache-smq.profile etc/lvm/profile/command_profile_template.profile etc/lvm/profile/lvmdbusd.profile etc/lvm/profile/metadata_profile_template.profile etc/lvm/profile/thin-generic.profile etc/lvm/profile/thin-performance.profile etc/lvm/profile/vdo-small.profile scripts/init-bottom/lvm2 scripts/local-block/lvm2 scripts/local-top/lvm-workaround scripts/local-top/lvm2 usr/lib/udev/rules.d/56-lvm.rules usr/lib/udev/rules.d/69-lvm-metad.rules usr/sbin/lvm root@it05:/# update-initramfs -u update-initramfs: Generating /boot/initrd.img-5.19.0-76051900-generic cryptsetup: WARNING: Resume target cryptswap uses a key file kernelstub.Config : INFO Looking for configuration... kernelstub.Drive : ERROR Could not find a block device for the a partition. This is a critical error and we cannot continue. Traceback (most recent call last): File "/usr/lib/python3/dist-packages/kernelstub/drive.py", line 56, in __init__ self.esp_fs = self.get_part_dev(self.esp_path) File "/usr/lib/python3/dist-packages/kernelstub/drive.py", line 94, in get_part_dev raise NoBlockDevError('Couldn't find the block device for %s' % path) kernelstub.drive.NoBlockDevError: Couldn't find the block device for /boot/efi run-parts: /etc/initramfs/post-update.d//zz-kernelstub exited with return code 174 root@it05:/# lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ├─sda1 │ vfat FAT32 D499-28CF ├─sda2 │ vfat FAT32 D499-2B97 ├─sda3 │ ext4 1.0 9f1f68bb-xxxx-xxxx-xxxx-xxxxxxxxxxxx └─sda4 swap 1 1758e7a0-xxxx-xxxx-xxxx-xxxxxxxxxxxx └─cryptswap swap 1 cryptswap e874c9cc-xxxx-xxxx-xxxx-xxxxxxxxxxxx [SWAP] sdb LVM2_m LVM2 wRBz38-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx └─workvg-root ext4 1.0 9f1f68bb-xxxx-xxxx-xxxx-xxxxxxxxxxxx 448.6G 46% / root@it05:/# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/workvg-root 916G 421G 449G 49% / tmpfs 7.8G 0 7.8G 0% /dev/shm tmpfs 1.6G 2.4M 1.6G 1% /run root@it05:/# mount /dev/sda1 /boot/efi root@it05:/# update-initramfs -u update-initramfs: Generating /boot/initrd.img-5.19.0-76051900-generic cryptsetup: WARNING: Resume target cryptswap uses a key file kernelstub.Config : INFO Looking for configuration... kernelstub : INFO System information: OS:..................Pop!_OS 22.04 Root partition:....../dev/dm-1 Root FS UUID:........9f1f68bb-xxxx-xxxx-xxxx-xxxxxxxxxxxx ESP Path:............/boot/efi ESP Partition:......./dev/sda1 ESP Partition #:.....1 NVRAM entry #:.......-1 Boot Variable #:.....0000 Kernel Boot Options:.quiet loglevel=0 systemd.show_status=false splash Kernel Image Path:.../boot/vmlinuz-5.19.0-76051900-generic Initrd Image Path:.../boot/initrd.img-5.19.0-76051900-generic Force-overwrite:.....False kernelstub.Installer : INFO Copying Kernel into ESP kernelstub.Installer : INFO Copying initrd.img into ESP kernelstub.Installer : INFO Setting up loader.conf configuration kernelstub.Installer : INFO Making entry file for Pop!_OS kernelstub.Installer : INFO Backing up old kernel kernelstub.Installer : INFO Making entry file for Pop!_OS ok, moment of truth, can i reboot into the new root filesystem root@it05:/# shutdown -r now Running in chroot, ignoring request. root@it05:/# exit root@work# shutdown -r now Whoot! Success. Booted right back up, and can verify running from new LV rhorning@icon-n.com@it05:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/workvg-root 916G 421G 449G 49% / /dev/sda1 497M 373M 125M 76% /boot/efi Next step, add the original root partition (/dev/sda3) to the volume group so there is 1.5Gb available to the filesystem root@work# pvcreate /dev/sda3 WARNING: ext4 signature detected on /dev/sda3 at offset 1080. Wipe it? [y/n]: y Wiping ext4 signature on /dev/sda3. Physical volume "/dev/sda3" successfully created. root@work# vgextend workvg /dev/sda3 Volume group "workvg" successfully extended root@work# vgdisplay --- Volume group --- VG Name workvg System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 2 Act PV 2 VG Size

In this episode we are going to look at Configuring Initial Switch Settings.We will perform basic switch configuration tasks. We will secure access to the command-line interface (CLI) and console ports using encrypted and plain text passwords. We will also learn how to configure messages for users logging into the switch. These message banners are also used to warn unauthorized users that access is prohibited.We will be discussing verifying the Default Switch Configuration, Configuring a Basic Switch Configuration, Configuring a MOTD Banner, and Saving Configuration Files to NVRAM.Thank you so much for watching this episode of my series on Configuration Examples for the Cisco Certified Network Associate (CCNA).Once again, I'm Kevin and this is KevTechify. Let's get this adventure started.All my details and contact information can be found on my website, https://KevTechify.comYouTube Channel: https://YouTube.com/KevTechify-------------------------------------------------------Cisco Certified Network Associate (CCNA)                                                                                                                                      Configuration Examples for Introduction to Networks v1 (ITN)Basic Switch and End Device ConfigurationLab 2.5.5 - Configure Initial Switch SettingsLab Number: 3Pod Number: 3Season: 1-------------------------------------------------------Equipment I like.Home Lab ►► https://kit.co/KevTechify/home-labNetworking Tools ►► https://kit.co/KevTechify/networking-toolsStudio Equipment ►► https://kit.co/KevTechify/studio-equipment 

Pinball: In pinball news the guys discuss the crowdfunding effort of The Pinball Company being cancelled, and Retro Atomic Zombie Adventureland (RAZA) having a video out of deeproot studios. They then have a broad discussion of mystery awards in pinball and also cover the results of their NVRAM giveaway. The conclude the segment with 20 Questions. Video Games: Discussion revolves around Zaccaria Pinball's new update on Steam and their announced progress towards their new mobile apps. The guys then walk through some major Overwatch changes, cover a bit of Minecraft news, and touch on several other smaller video game happenings. Episode Links: Retro Atomic Zombie Adventureland video: https://www.youtube.com/watch?v=opAK-32MfJM Show Links: Website: http://eclecticgamers.com iTunes: http://itunes.apple.com/us/podcast/eclectic-gamers-podcast/id1088802706?mt=2 SoundCloud: https://soundcloud.com/user-465086826 Stitcher: http://www.stitcher.com/s?fid=86805 Facebook: http://www.facebook.com/eclecticgamerspodcast/ Twitter: https://twitter.com/Eclectic_gamers Twitch: https://www.twitch.tv/eclectic_gamers YouTube: https://www.youtube.com/channel/UC40Frd1Fep4u5bjrw3cvwoQ Discord: https://discord.gg/sgnrsBT Email: eclecticgamerspodcast@gmail.com

Nick Baldridge (For Amusement Only: The EM & Bingo Pinball Podcast and Gaming on Ten Minutes a Week) joins us to discuss the new publication he co-authored with Ryan Claytor called Coin-Op Carnival: Electrifying Tales of Mechanical Contraptions. Pinball: Discussion revolves entirely around the upcoming Coin-Op Carnival publication, with a hefty dose of EM discussion sprinkled throughout. Also, Nick plays a game of 20 Questions. Video Games: The news features and update regarding Activision-Blizzard and also Bioware's game Anthem. From there, another varied discussion ensues regarding video games in general. Listen during the episode's pinball segment to learn how to enter to win a copy of Coin-Op Carnival (worldwide) and/or an NVRAM chip (U.S. only)! Episode Links: Pinball Profile episode 182: http://www.podcastgarden.com/episode/ep-182-dennis-kriesel-eclectic-gamers-podcast-host_141759 Coin-Op Carnival: Electrifying Tales of Mechanical Contraptions: http://www.coinopcarnival.com/ For Amusement Only: The EM & Bingo Pinball Podcast: https://foramusementonly.libsyn.com/ Gaming on Ten Minutes a Week: https://gamingontenminutesaweek.libsyn.com/ Show Links: Website: http://eclecticgamers.com iTunes: http://itunes.apple.com/us/podcast/eclectic-gamers-podcast/id1088802706?mt=2 SoundCloud: https://soundcloud.com/user-465086826 Stitcher: http://www.stitcher.com/s?fid=86805 Facebook: http://www.facebook.com/eclecticgamerspodcast/ Twitter: https://twitter.com/Eclectic_gamers Twitch: https://www.twitch.tv/eclectic_gamers YouTube: https://www.youtube.com/channel/UC40Frd1Fep4u5bjrw3cvwoQ Discord: https://discord.gg/sgnrsBT Email: eclecticgamerspodcast@gmail.com

Bez zbędnych ceregieli, zapraszamy do odsłuchu dłuższego niż ostatnio kompotu. Tytuł zdradza o czym rozmawiamy w sześćdziesiątym odcinku, zatem poniżej tylko dodamy odsyłacze do omawianych programów i usług: bjango iStat Menus, Noodlesoft Hazel, MacPaw CleanMyMac, Marcus Amalthea Magnuson / Kumaran Vijayan AppTrap, MacPaw Gemini, Software Ambience DaisyDisk, Koingo Software Inc. MacPilot, Titanium Software OnyX, Etresoft EtreCheck, Tunabelly Software TG Pro, wsparcie Apple: Resetowanie kontrolera zarządzania systemem (SMC) na komputerze Mac, wsparcie Apple: Resetowanie pamięci NVRAM lub PRAM w komputerze Mac, wsparcie Apple: Lokalne migawki Time Machine, wyłączenie w Terminalu: sudo tmutil disablelocal Wsparcie Apple: Odbudowywanie indeksu funkcji Spotlight na komputerze Mac, odbudowywanie w Terminalu: sudo mdutil -i on / Nasz podkast znajdziecie w iTunes (link), możecie też dodać do swojego ulubionego czytnika RSS (link), wysłuchać w serwisie Spotify (link) lub przesłuchać bezpośrednio w przeglądarce (link). Zapraszamy do kontaktu na Twitterze: Remek Rychlewski @RZoG. Marek Telecki @mantis30. Natomiast całe przedsięwzięcie firmuje konto @ApplejuicePl. Jesteśmy również dostępni dla Was pod adresem e-mail kompot[at]applejuice.pl

In this episode, we answer: 1. What is the difference between the Data Plane and the Control Plane? 2:34 2. "Can you explain in-depth the difference between #Tor and #I2P and the risks for information leakage in each?" 6:47 3. "Advantage of Azure Active Directory over AD?" 14:32 4. NVRAM and Flash, are both persistent through reboots, what is the difference? 22:48 5. How is an IPv6 Anycast Address Secured? 29:15 6. "Do you have any content like CWNA, or similar, involving in depth wireless topics?" 34:25

GSoC 2018 Projects announced, tutorial FreeBSD jails with iocage, new Code of Conduct for FreeBSD, libhijack, and fancy monitoring for OpenSMTPD This episode was brought to you by Headlines Google Summer of Code 2018 (https://summerofcode.withgoogle.com/organizations/?sp-page=5) FreeBSD (https://www.freebsd.org/projects/summerofcode.html) FreeBSD Google Summer oF Code Ideas (https://wiki.freebsd.org/SummerOfCodeIdeas) You can join #freebsd-soc on the efnet IRC network to chat with FreeBSD developers interested in mentoring student proposals and projects, past FreeBSD/GSoC students, and other students applying to FreeBSD/GSoC this year. NetBSD (https://mail-index.netbsd.org/netbsd-advocacy/2018/02/12/msg000765.html) You can get a stipend (paid for by Google) and spend a few months getting to know and improving the insides of NetBSD or pkgsrc. ``` The schedule is: 12-27 March Applying 23 April Find out if you were accepted 14 May - 22 August Do the project! We have some suggestions for suitable projects: - ARM EFI bootloader - Using libFuzzer on base tools - Refactoring ALTQ (QoS implementation) and integrating with NPF - Testsuite for libcurses - Improve pkgin Other suggestions and details are at: https://wiki.netbsd.org/projects/gsoc/ ``` These projects are suggestions; you can come up with your own. Suggestions for other suitable projects are welcome. Feel free to contact, or chat around on IRC: irc.freenode.org #netbsd #netbsd-code #pkgsrc Haiku (https://summerofcode.withgoogle.com/organizations/4821756754264064/) Students: How to Apply for a Haiku Idea (https://www.haiku-os.org/community/gsoc/2018/students) Project Ideas (https://www.haiku-os.org/community/gsoc/2018/ideas) > If you have questions you can contact the devs on IRC: irc.freenode.org #haiku FreeBSD Jails with iocage (http://norrist.devio.us/iocage_freebsd.html) Introduction FreeBSD jails allow users to run multiple, isolated instances of FreeBSD on a single server. Iocage simplifies the management of FreeBSD Jails. Following this tutorial, the jails will be configured to bind to an IP address on the jail host's internal network, and the host OS will pass traffic from the external network to the jail. The jails will be managed with Iocage. Iocage uses ZFS properties to store configuration data for each jail, so a ZFS file system is required. Network setup These steps will: Set up the internal network. Enable the pf packet filter Configure pf pass internet traffic to and from the jail. PF is full featured firewall, and can do more than just pass traffic to an internal network. Refer to the PF documentation for additional configuration options. Run the following to configure the internal network and enable pf. sysrc cloned_interfaces+="lo1" sysrc ifconfig_lo1="inet 192.0.2.1/24" sysrc pf_enable="YES" Put the following in /etc/pf.conf ``` Variables ext_if should be set to the hosts external NIC extif = "vtnet0" jailif = "lo1" jailnet = $jailif:network NAT allows the jails to access the external network nat on $extif from $jailnet to any -> ($ext_if) Redirect traffic on port 80 to the web server jail Add similar rules for additional jails rdr pass on $ext_if inet proto tcp to port 80 -> 192.0.2.10 ``` Reboot to activate the network changes ZFS The best way to use ZFS on a VPS is to attach block storage as a new disk. If block storage is not available, you can optionally use a file as the ZFS device. Enable and start ZFS. sysrc zfs_enable="YES" service zfs start ZFS using Block storage List the available disks. If you are using a VPS, the block store will probably be the second disk. geom disk list Create a ZFS pool named jailstore. zpool create jailstore /dev/vtbd1 ZFS using a file Create the ZFS file. dd if=/dev/zero of=/zfsfile bs=1M count=4096 Create a ZFS pool named jailstore. zpool create jailstore /zfsfile Install iocage the easy way pkg install py36-iocage Skip to "Using iocage" Install iocage the hard way Swap file Smaller servers may not have enough RAM to build iocage. If needed, create a swap file and reboot. dd if=/dev/zero of=/swapfile bs=1M count=1024 echo 'swapfile="/swapfile"' >> /etc/rc.conf reboot Install some build dependencies pkg install subversion python36 git-lite libgit2 py36-pip Building iocage requires the FreeBSD source. svn checkout https://svn.freebsd.org/base/releng/11.1 /usr/src Get the latest FreeBSD ports tree. ``` portsnap fetch portsnap extract ``` + build iocage. cd /usr/ports/sysutils/iocage/ make install Using iocage ``` iocage activate jailstore iocage fetch iocage create -n www ip4_addr="lo1|192.0.2.10/24" -r 11.1-RELEASE iocage start www iocage console www ``` Once you have a shell inside the jail, install and start Apache. pkg install apache24 sysrc apache24_enable="yes" service apache24 start Port 80 on the jail will now be accessible on the hosts IP address. Multiple jails. Additional jails can be installed using the example above. Install the new jail with the iocage create command , but use a different IP address Expose the new jail to the network by adding additional rules to pf.conf. iXsystems SNIA Persistent Memory Summit 2018 Report (https://www.ixsystems.com/blog/snia-report-2018/) New FreeBSD Code of Conduct (https://www.freebsd.org/internal/code-of-conduct.html) The FreeBSD Project is inclusive. We want the FreeBSD Project to be a venue where people of all backgrounds can work together to make the best operating system, built by a strong community. These values extend beyond just development to all aspects of the Project. All those given recognition as members of the Project in whatever form are seen as ambassadors of the Project. Diversity is a huge strength and is critical to the long term success of the Project. To that end we have a few ground rules that we ask people to adhere to. This code applies equally to everyone representing the FreeBSD Project in any way, from new members, to committers, to the core team itself. These rules are intended to ensure a safe, harassment-free environment for all and to ensure that everyone feels welcome both working within, and interacting with, the Project. This document is not an exhaustive list of things that you should not do. Rather, consider it a guide to make it easier to enrich all of us and the technical communities in which we participate. This code of conduct applies to all spaces used by the FreeBSD Project, including our mailing lists, IRC channels, and social media, both online and off. Anyone who is found to violate this code of conduct may be sanctioned or expelled from FreeBSD Project controlled spaces at the discretion of the FreeBSD Code of Conduct Committee. Some FreeBSD Project spaces may have additional rules in place, which will be made clearly available to participants. Participants are responsible for knowing and abiding by these rules. Harassment includes but is not limited to: + Comments that reinforce systemic oppression related to gender, gender identity and expression, sexual orientation, disability, mental illness, neurodiversity, physical appearance, body size, age, race, or religion. + Unwelcome comments regarding a person's lifestyle choices and practices, including those related to food, health, parenting, drugs, and employment. + Deliberate misgendering. + Deliberate use of "dead" or rejected names. + Gratuitous or off-topic sexual images or behaviour in spaces where they're not appropriate. + Physical contact and simulated physical contact (e.g., textual descriptions like "hug" or "backrub") without consent or after a request to stop. + Threats of violence. + Incitement of violence towards any individual, including encouraging a person to commit suicide or to engage in self-harm. + Deliberate intimidation. + Stalking or following. + Harassing photography or recording, including logging online activity for harassment purposes. + Sustained disruption of discussion. + Unwelcome sexual attention. + Pattern of inappropriate social contact, such as requesting/assuming inappropriate levels of intimacy with others. + Continued one-on-one communication after requests to cease. + Deliberate "outing" of any private aspect of a person's identity without their consent except as necessary to protect vulnerable people from intentional abuse. + Publication of non-harassing private communication without consent. + Publication of non-harassing private communication with consent but in a way that intentionally misrepresents the communication (e.g., removes context that changes the meaning). + Knowingly making harmful false claims about a person. Interview - Benno Rice - benno@freebsd.org (mailto:benno@freebsd.org) / @jeamland (https://twitter.com/jeamland) News Roundup libhijack in PoC||GTFO 0x17! (https://www.soldierx.com/news/libhijack-PoCGTFO-0x17) Hijacking Your Free Beasties In the land of red devils known as Beasties exists a system devoid of meaningful exploit mitigations. As we explore this vast land of opportunity, we will meet our ELFish friends, [p]tracing their very moves in order to hijack them. Since unprivileged process debugging is enabled by default on FreeBSD, we can abuse PTrace to create anonymous memory mappings, inject code into them, and overwrite PLT/GOT entries. We will revive a tool called libhijack to make our nefarious activities of hijacking ELFs via PTrace relatively easy. Nothing presented here is technically new. However, this type of work has not been documented in this much detail, tying it all into one cohesive work. In Phrack 56, Silvio Cesare taught us ELF research enthusiasts how to hook the PLT/GOT. The Phrack 59 article on Runtime Process Infection briefly introduces the concept of injecting shared objects by injecting shellcode via PTrace that calls dlopen(). No other piece of research, however, has discovered the joys of forcing the application to create anonymous memory mappings in which to inject Code. This is only part one of a series of planned articles that will follow libhijack's development. The end goal is to be able to anonymously inject shared objects. The libhijack project is maintained by the SoldierX community. Previous Research All prior work injects code into the stack, the heap, or existing executable code. All three methods create issues on today's systems. On amd64 and arm64, the two architectures libhijack cares about, the stack is non-executable by default. jemalloc, the heap implementation on FreeBSD, creates non-executable mappings. Obviously overwriting existing executable code destroys a part of the executable image. The Role of ELF > FreeBSD provides a nifty API for inspecting the entire virtual memory space of an application. The results returned from the API tells us the protection flags (readable, writable, executable) of each mapping. If FreeBSD provides such a rich API, why would we need to parse the ELF headers? PLT/GOT hijacking requires parsing ELF headers. One would not be able to find the PLT/GOT without iterating through the Process Headers to find the Dynamic Headers, eventually ending up with the DT_PLTGOT entry. With FreeBSD's libprocstat API, we don't have a need for parsing ELF headers until we get to the PLT/GOT stage, but doing so early makes it easier for the attacker using libhijack The Future of libhijack Writing devious code in assembly is cumbersome. Assembly doesn't scale well to multiple architectures. Instead, we would like to write our devious code in C, compiling to a shared object that gets injected anonymously. This requires writing a remote RTLD within libhijack and is in progress. Writing a remote RTLD will take a while as doing so is not an easy task. Additionally, creation of a general-purpose helper library that gets injected would be helpful. It could aid in PLT/GOT redirection attacks, possibly storing the addresses of functions we've previously hijacked. This work is dependent on the remote RTLD. libhijack currently lacks documentation. Once the ABI and API stabilize, formal documentation will be written. Conclusion Using libhijack, we can easily create anonymous memory mappings, inject into them arbitrary code, and hijack the PLT/GOT on FreeBSD. On HardenedBSD, a hardened derivative of FreeBSD, libhijack is fully mitigated through PaX NOEXEC. We've demonstrated that wrapper-style Capsicum is ineffective on FreeBSD. Through the use of libhijack, we emulate a control flow hijack in which the application is forced to call sandbox_open and fdlopen on the resulting file descriptor. Further work to support anonymous injection of full shared objects, along with their dependencies, will be supported in the future. Imagine injecting libpcap into Apache to sniff traffic whenever "GET /pcap" is sent. In order to prevent abuse of PTrace, FreeBSD should set the security.bsd.unprivilegedprocdebug to 0 by default. In order to prevent process manipulation, FreeBSD should implement PaX NOEXEC. libhijack can be found at https://github.com/SoldierX/libhijack Introduction to POSIX shell (https://sircmpwn.github.io/2018/02/05/Introduction-to-POSIX-shell.html) What the heck is the POSIX shell anyway? Well, the POSIX (the Portable Operating System Interface) shell is the standard Unix shell - standard meaning it was formally defined and shipped in a published standard. This makes shell scripts written for it portable, something no other shell can lay claim to. The POSIX shell is basically a formalized version of the venerable Bourne shell, and on your system it lives at /bin/sh, unless you're one of the unlucky masses for whom this is a symlink to bash. Why use POSIX shell? The “Bourne Again shell”, aka bash, is not standardized. Its grammar, features, and behavior aren't formally written up anywhere, and only one implementation of bash exists. Without a standard, bash is defined by its implementation. POSIX shell, on the other hand, has many competing implementations on many different operating systems - all of which are compatible with each other because they conform to the standard. Any shell that utilizes features specific to Bash are not portable, which means you cannot take them with you to any other system. Many Linux-based systems do not use Bash or GNU coreutils. Outside of Linux, pretty much everyone but Hurd does not ship GNU tools, including bash1. On any of these systems, scripts using “bashisms” will not work. This is bad if your users wish to utilize your software anywhere other than GNU/Linux. If your build tooling utilizes bashisms, your software will not build on anything but GNU/Linux. If you ship runtime scripts that use bashisms, your software will not run on anything but GNU/Linux. The case for sticking to POSIX shell in shipping software is compelling, but I argue that you should stick to POSIX shell for your personal scripts, too. You might not care now, but when you feel like flirting with other Unicies you'll thank me when all of your scripts work. One place where POSIX shell does not shine is for interactive use - a place where I think bash sucks, too. Any shell you want to use for your day-to-day command line work is okay in my book. I use fish. Use whatever you like interactively, but stick to POSIX sh for your scripts. How do I use POSIX shell? At the top of your scripts, put #!/bin/sh. You don't have to worry about using env here like you might have been trained to do with bash: /bin/sh is the standardized location for the POSIX shell, and any standards-conforming system will either put it there or make your script work anyway. The next step is to avoid bashisms. There are many, but here are a few that might trip you up: [[ condition ]] does not work; use [ condition ] Arrays do not work; use IFS Local variables do not work; use a subshell The easiest way to learn about POSIX shell is to read the standard - it's not too dry and shorter than you think. Using standard coreutils The last step to writing portable scripts is to use portable tools. Your system may have GNU coreutils installed, which provides tools like grep and cut. Unfortunately, GNU has extended these tools with its own non-portable flags and tools. It's important that you avoid these. One dead giveaway of a non-portable flag is long flags, e.g. grep --file=FILE as opposed to grep -f. The POSIX standard only defines the getopt function - not the proprietary GNU getopt_long function that's used to interpret long options. As a result, no long flags are standardized. You might worry that this will make your scripts difficult to understand, but I think that on the whole it will not. Shell scripts are already pretty alien and require some knowledge to understand. Is knowledge of what the magic word grep means much different from knowledge of what grep -E means? I also like that short flags allow you to make more concise command lines. Which is better: ps --all --format=user --without-tty, or ps -aux? If you are inclined to think the former, do you also prefer function(a, b, c) { return a + b + c; } over (a, b, c) => a + b + c? Conciseness matters, and POSIX shell supports comments if necessary! Some tips for using short flags: They can be collapsed: cmd -a -b -c is equivalent to cmd -abc If they take additional arguments, either a space or no separation is acceptable: cmd -f"hello world" or cmd -f "hello world" A good reference for learning about standardized commands is, once again, the standard. From this page, search for the command you want, or navigate through “Shell & Utilities” -> “Utilities” for a list. If you have man-pages installed, you will also find POSIX man pages installed on your system with the p postfix, such as man 1p grep. Note: at the time of writing, the POSIX man pages do not use dashes if your locale is UTF-8, which makes searching for flags with / difficult. Use env LC_ALL=POSIX man 1p grep if you need to search for flags, and I'll speak to the maintainer of man-pages about this. FreeBSD Broadcom Wi-Fi Improvements (http://landonf.org/code/freebsd/Broadcom_WiFi_Improvements.20180122.html) Introduction Since 2015, I've been working on improving FreeBSD support for Broadcom Wi-Fi devices and SoCs, including authoring the bhnd(4) driver family, which provides a unified bus and driver programming interface for these devices. First committed in early 2016, bhnd(4) allowed us to quickly bring up FreeBSD/MIPS on Broadcom SoCs, but it has taken much longer to implement the full set of features required to support modern Broadcom SoftMAC Wi-Fi hardware. Thanks to the generosity of the FreeBSD Foundation, I've recently finished implementing the necessary improvements to the bhnd(4) driver family. With these changes in place, I was finally able to port the existing bwn(4) Broadcom SoftMAC Wi-Fi driver to the bhnd(4) bus, and implement initial support for the BCM43224 and BCM43225 chipsets, with additional hardware support to be forthcoming. Now that my efforts on FreeBSD/Broadcom Wi-Fi support have progressed far enough to be generally useful, I wanted to take some time to provide a brief overview of Broadcom's Wi-Fi hardware, and explain how my work provides a foundation for further FreeBSD Broadcom Wi-Fi/SoC improvements. A Brief Background on Broadcom Wi-Fi Hardware Broadcom's Wi-Fi devices are members of the Broadcom Home Networking Division (BHND) device family; other BHND devices include MIPS/ARM SoCs (including Wi-Fi SoCs commonly found in consumer access points), as well as a large variety of related networking hardware. BHND devices utilize a common set of Broadcom IP cores (or "functional blocks") connected via one of two on-chip bus architectures: Hardware designed prior to 2009 used Broadcom's “SSB” backplane architecture, based on Sonics Silicon's interconnect IP. Subsequent hardware adopted Broadcom's “BCMA” backplane, based on ARM's AMBA IP. The IP cores used in earlier SSB-based devices were adapted for compatibility with the new backplane. When BHND hardware is used in a PCI Wi-Fi card, or a SDIO Wi-Fi module, the device's dual-mode peripheral controller is configured to operate as an endpoint device on the host's peripheral bus, bridging access to the SoC hardware: Host access to SoC address space is provided via a set of register windows (e.g., a set of configurable windows into SoC address space mapped via PCI BARs) DMA is supported by the bridge core's sparse mapping of host address space into the backplane address space. These address regions may be used as a target for the on-chip DMA engines. Any backplane interrupt vectors routed to the bridge core may be mapped by the bridge to host interrupts (e.g., PCI INTx/MSI/MSI-X). The host is generally expected to provide drivers for the IP cores found on the SoC backplane; since these cores are found in both BHND SoCs and BHND Wi-Fi devices, it is advantageous to share driver and platform code between the two targets. Modernizing FreeBSD's Broadcom SoftMAC Wi-Fi Support FreeBSD support for Broadcom SoftMAC Wi-Fi adapters is provided by two partially overlapping PCI/CardBus drivers: Legacy Wi-Fi adapters are supported by bwi(4). This driver remains in-tree to support devices incompatible with v4 or later firmware (e.g. BCM4301, BCM4302, BCM4306 rev 1-2), all of which were released prior to December 2002. Modern Wi-Fi adapters are supported by bwn(4), with access to on-chip cores mediated by bhnd(4). Prior to my work porting bwn(4) to bhnd(4), access to on-chip cores was mediated by sibabwn, a PCI/WiFi-specific derivative of the legacy siba(4) SSB bus driver. There were two major limitations to sibabwn that have long blocked adding support for newer SoftMAC Wi-Fi chipsets: the newer BCMA interconnect found in post-2009 hardware was not supported by siba(4), and siba_bwn assumed a PCI/PCIe bridge, preventing its use on FreeBSD/MIPS Broadcom SoCs with interconnect-attached D11 cores. The new bhnd(4) driver family, written as a replacement for siba(4) and siba_bwn, provides: A unified bus driver interface for both SSB and BCMA on-chip interconnects A generic BHND bridge driver framework for host-connected BHND devices (e.g. Wi-Fi adapters, etc) A PCI/PCIe bridge core driver, for PCI-attached BHND devices. An abstract BHND NVRAM API, with support for the varied NVRAM formats found in BHND Wi-Fi adapters and SoCs. Drivers for common BHND platform peripherals (UARTs, SPROM/flash, PMUs, etc) By porting bwn(4) to bhnd(4), we are now able to support existing BCMA devices with MAC/PHY/Radio combinations readily supported by bwn(4), as was the case with the BCM43224 and BCM43225 chipsets. This also opens the door to porting additional PHY support from Broadcom's ISC-licensed Linux drivers, and will allow us to bring up bwn(4) on Broadcom WiSoCs supported by FreeBSD/MIPS. Monitor OpenSMTPD using Logstash and Grafana (https://www.tumfatig.net/20180129/monitor-opensmtpd-using-logstash-grafana/) Logs are usefull. Graphs are sexy. Here's a way to get a view on what happens to your OpenSMTPD traffic, using Web v2.0 tools ; namely Logstash & Grafana. For those who would not be aware of those tools, logstash is some kind of log-parser that can eat syslog formatted logs and write them into elasticsearch ; in “document” format. Grafana is a Web frontend that can dig into various databases and render graphics from requests. I won't go into the whole “how to install” process here. Installation is quite straight forward and online documentation is quite clear. What you need OpenSMTPD deals with emails and logs its activity via Syslog. Syslog is configured to send the logs to Logstash. Logstash has a set of rules configured to transform the text-oriented information into searchable document-oriented data. The transformed data is stored into Elasticsearch. Elasticsearch provides Web API to search and find stuff. Grafana connects to ELS to get data and draw the graphs. Beastie Bits CharmBUG Presentation - Writing FreeBSD Malware (https://www.meetup.com/CharmBUG/events/247995596/) March London *BSD meeting 13/03/18 (http://mailman.uk.freebsd.org/pipermail/ukfreebsd/2018-February/014180.html) FreBSD Ports Workshop (https://wiki.freebsd.org/MateuszPiotrowski/Ports/Workshop) The history of NetBSD/atari and support for ATARI compatible Milan / OSC2018Osaka (https://speakerdeck.com/tsutsui/osc2018osaka) SSH Mastery, 2nd Edition (https://www.tiltedwindmillpress.com/?product=ssh-mastery-2nd-edition) *** Feedback/Questions Stephen - Viewer Interview Question (http://dpaste.com/06WTRB9#wrap) pb - trust expanding your 280TB pool (http://dpaste.com/0TZV6CM#wrap) Tim - ZFS questions for the ZFS Man (http://dpaste.com/0759X1E#wrap) Daniel - ZFS full backup question (http://dpaste.com/1SJXSBQ#wrap) ***

What's up with PRAM, NVRAM and SMC? What about the APFS migration? It's alphabet soup this week on Query!

This week on BSDNow, we've got all sorts of post-holiday goodies to share. New OpenSSL APIs, Dtrace, OpenBSD This episode was brought to you by Headlines OpenSSL 1.1 API migration path, or the lack thereof (https://www.mail-archive.com/tech@openbsd.org/msg36437.html) As many of you will already be aware, the OpenSSL 1.1.0 release intentionally introduced significant API changes from the previous release. In summary, a large number of data structures that were previously publically visible have been made opaque, with accessor functions being added in order to get and set some of the fields within these now opaque structs. It is worth noting that the use of opaque data structures is generally beneficial for libraries, since changes can be made to these data structures without breaking the ABI. As such, the overall direction of these changes is largely reasonable. However, while API change is generally necessary for progression, in this case it would appear that there is NO transition plan and a complete disregard for the impact that these changes would have on the overall open source ecosystem. So far it seems that the only approach is to place the migration burden onto each and every software project that uses OpenSSL, pushing significant code changes to each project that migrates to OpenSSL 1.1, while maintaining compatibility with the previous API. This is forcing each project to provide their own backwards compatibility shims, which is practically guaranteeing that there will be a proliferation of variable quality implementations; it is almost a certainty that some of these will contain bugs, potentially introducing security issues or memory leaks. I think this will be a bigger issue for other operating systems that do not have the flexibility of the ports tree to deliver a newer version of OpenSSL. If a project switches from the old API to the new API, and the OS only provides the older branch of OpenSSL, how can the application work? Of course, this leaves the issue, if application A wants OpenSSL 1.0, and application B only works with OpenSSL 1.1, how does that work? Due to a number of factors, software projects that make use of OpenSSL cannot simply migrate to the 1.1 API and drop support for the 1.0 API - in most cases they will need to continue to support both. Firstly, I am not aware of any platform that has shipped a production release with OpenSSL 1.1 - any software that supported OpenSSL 1.1 only, would effectively be unusable on every platform for the time being. Secondly, the OpenSSL 1.0.2 release is supported until the 31st of December 2019, while OpenSSL 1.1.0 is only supported until the 31st of August 2018 - any LTS style release is clearly going to consider shipping with 1.0.2 as a result. Platforms that are attempting to ship with OpenSSL 1.1 are already encountering significant challenges - for example, Debian currently has 257 packages (out of 518) that do not build against OpenSSL 1.1. There are also hidden gotchas for situations where different libraries are linked against different OpenSSL versions and then share OpenSSL data structures between them - many of these problems will be difficult to detect since they only fail at runtime. It will be interesting to see what happens with OpenSSL, and LibreSSL Hopefully, most projects will decide to switch to the cleaner APIs provided by s2n or libtls, although they do not provide the entire functionality of the OpenSSL API. Hacker News comments (https://news.ycombinator.com/item?id=13284648) *** exfiltration via receive timing (http://www.tedunangst.com/flak/post/exfiltration-via-receive-timing) Another similar way to create a backchannel but without transmitting anything is to introduce delays in the receiver and measure throughput as observed by the sender. All we need is a protocol with transmission control. Hmmm. Actually, it's easier (and more reliable) to code this up using a plain pipe, but the same principle applies to networked transmissions. For every digit we want to “send” back, we sleep a few seconds, then drain the pipe. We don't care about the data, although if this were a video file or an OS update, we could probably do something useful with it. Continuously fill the pipe with junk data. If (when) we block, calculate the difference between before and after. This is a our secret backchannel data. (The reader and writer use different buffer sizes because on OpenBSD at least, a writer will stay blocked even after a read depending on the space that opens up. Even simple demos have real world considerations.) In this simple example, the secret data (argv) is shared by the processes, but we can see that the writer isn't printing them from its own address space. Nevertheless, it works. Time to add random delays and buffering to firewalls? Probably not. An interesting thought experiment that shows just how many ways there are to covertly convey a message *** OpenBSD Desktop in about 30 Minutes (https://news.ycombinator.com/item?id=13223351) Over at hackernews we have a very non-verbose, but handy guide to getting to a OpenBSD desktop in about 30 minutes! First, the guide will assume you've already installed OpenBSD 6.0, so you'll need to at least be at the shell prompt of your freshly installed system to begin. With that, now its time to do some tuning. Editing some resource limits in login.conf will be our initial task, upping some datasize tunables to 2GB Next up, we will edit some of the default “doas” settings to something a bit more workable for desktop computing Another handy trick, editing your .profile to have your PKG_PATH variables set automatically will make One thing some folks may overlook, but disabling atime can speed disk performance (which you probably don't care about atime on your desktop anyway), so this guide will show you what knobs to tweak in /etc/fstab to do so After some final WPA / Wifi configuration, we then drop to “mere mortal” mode and begin our package installations. In this particular guide, he will be setting up Lumina Desktop (Which yes, it is on OpenBSD) A few small tweaks later for xscreensaver and your xinitrc file, then you are ready to run “startx” and begin your desktop session! All in all, great guide which if you are fast can probably be done in even less than 30 minutes and will result in a rock-solid OpenBSD desktop rocking Lumina none-the-less. *** How DTrace saved Christmas (https://hackernoon.com/dtrace-at-home-145ba773371e) Adam Leventhal, one of the co-creators of DTrace, wrote up this post about how he uses DTrace at home, to save Christmas I had been procrastinating making the family holiday card. It was a combination of having a lot on my plate and dreading the formulation of our annual note recapping the year; there were some great moments, but I'm glad I don't have to do 2016 again. It was just before midnight and either I'd make the card that night or leave an empty space on our friends' refrigerators. Adobe Illustrator had other ideas: “Unable to set maximum number of files to be opened” I'm not the first person to hit this. The problem seems to have existed since CS6 was released in 2016. None of the solutions were working for me, and — inspired by Sara Mauskopf's excellent post (https://medium.com/startup-grind/how-to-start-a-company-with-no-free-time-b70fbe7b918a#.uujdblxc6) — I was rapidly running out of the time bounds for the project. Enough; I'd just DTrace it. A colleague scoffed the other day, “I mean, how often do you actually use DTrace?” In his mind DTrace was for big systems, critical system, when dollars and lives were at stake. My reply: I use DTrace every day. I can't imagine developing software without DTrace, and I use it when my laptop (not infrequently) does something inexplicable (I'm forever grateful to the Apple team that ported it to Mac OS X) Illustrator is failing on setrlimit(2) and blowing up as result. Let's confirm that it is in fact returning -1:$ sudo dtrace -n 'syscall::setrlimit:return/execname == "Adobe Illustrato"/{ printf("%d %d", arg1, errno); }' dtrace: description 'syscall::setrlimit:return' matched 1 probe CPU ID FUNCTION:NAME 0 532 setrlimit:return -1 1 There it is. And setrlimit(2) is failing with errno 1 which is EPERM (value too high for non-root user). I already tuned up the files limit pretty high. Let's confirm that it is in fact setting the files limit and check the value to which it's being set. To write this script I looked at the documentation for setrlimit(2) (hooray for man pages!) to determine that the position of the resource parameter (arg0) and the type of the value parameter (struct rlimit). I needed the DTrace copyin() subroutine to grab the structure from the process's address space: $ sudo dtrace -n 'syscall::setrlimit:entry/execname == "Adobe Illustrato"/{ this->r = *(struct rlimit *)copyin(arg1, sizeof (struct rlimit)); printf("%x %x %x", arg0, this->r.rlimcur, this->r.rlimmax); }' dtrace: description 'syscall::setrlimit:entry' matched 1 probe CPU ID FUNCTION:NAME 0 531 setrlimit:entry 1008 2800 7fffffffffffffff Looking through /usr/include/sys/resource.h we can see that 1008 corresponds to the number of files (RLIMITNOFILE | _RLIMITPOSIX_FLAG) The quickest solution was to use DTrace again to whack a smaller number into that struct rlimit. Easy: $ sudo dtrace -w -n 'syscall::setrlimit:entry/execname == "Adobe Illustrato"/{ this->i = (rlimt *)alloca(sizeof (rlimt)); *this->i = 10000; copyout(this->i, arg1 + sizeof (rlimt), sizeof (rlimt)); }' dtrace: description 'syscall::setrlimit:entry' matched 1 probe dtrace: could not enable tracing: Permission denied Oh right. Thank you SIP (System Integrity Protection). This is a new laptop (at least a new motherboard due to some bizarre issue) which probably contributed to Illustrator not working when once it did. Because it's new I haven't yet disabled the part of SIP that prevents you from using DTrace on the kernel or in destructive mode (e.g. copyout()). It's easy enough to disable, but I'm reboot-phobic — I hate having to restart my terminals — so I went to plan B: lldb + After using DTrace to get the address of the setrlimit function, Adam used lldb to change the result before it got back to the application: (lldb) break set -n _init Breakpoint 1: 47 locations. (lldb) run … (lldb) di -s 0x1006e5b72 -c 1 0x1006e5b72: callq 0x1011628e0 ; symbol stub for: setrlimit (lldb) memory write 0x1006e5b72 0x31 0xc0 0x90 0x90 0x90 (lldb) di -s 0x1006e5b72 -c 4 0x1006e5b72: xorl %eax, %eax 0x1006e5b74: nop 0x1006e5b75: nop 0x1006e5b76: nop Next I just did a process detach and got on with making that holiday card… DTrace was designed for solving hard problems on critical systems, but the need to understand how systems behave exists in development and on consumer systems. Just because you didn't write a program doesn't mean you can't fix it. News Roundup Say my Blog's name! (https://functionallyparanoid.com/2016/12/22/say-my-blogs-name/) Brian Everly over at functionally paranoid has a treat for us today. Let us give you a moment to get the tin-foil hats on… Ok, done? Let's begin! He starts off with a look at physical security. He begins by listing your options: BIOS passwords – Not something I'm typically impressed with. Most can be avoided by opening up the machine, closing a jumper and powering it up to reset the NVRAM to factory defaults. I don't even bother with them. Full disk encryption – This one really rings my bell in a positive way. If you can kill power to the box (either because the bad actor has to physically steal it and they aren't carrying around a pile of car batteries and an inverter or because you can interrupt power to it some other way), then the disk will be encrypted. The other beauty of this is that if a drive fails (and they all do eventually) you don't have to have any privacy concerns about chucking it into an electronics recycler (or if you are a bad, bad person, into a landfill) because that data is effectively gibberish without the key (or without a long time to brute force it). Two factor auth for logins – I like this one as well. I'm not a fan of biometrics because if your fingerprint is compromised (yes, it can happen – read (https://www.washingtonpost.com/news/federal-eye/wp/2015/07/09/hack-of-security-clearance-system-affected-21-5-million-people-federal-authorities-say/) about the department of defense background checks that were extracted by a bad agent – they included fingerprint images) you can't exactly send off for a new finger. Things like the YubiKey (https://www.yubico.com/) are pretty slick. They require that you have the physical hardware key as well as the password so unless the bad actor lifted your physical key, they would have a much harder time with physical access to your hardware. Out of those options, Brian mentions that he uses disk encryption and yubi-key for all his secure network systems. Next up is network segmentation, in this case the first thing to do is change your admin password for any ISP supplied modem / router. He goes on to scare us of javascript attacks being used not against your local machine, but instead non WAN exposed router admin interface. Scary Stuff! For added security, naturally he firewalls the router by plugging in the LAN port to a OpenBSD box which does the 2nd layer of firewall / router protection. What about privacy and browsing? Here's some more of his tips: I use Unbound as my DNS resolver on my local network (with all UDP port 53 traffic redirected to it by pf so I don't have to configure anything on the clients) and then forward the traffic to DNSCrypt Proxy, caching the results in Unbound. I notice ZERO performance penalty for this and it greatly enhances privacy. This combination of Unbound and DNSCrypt Proxy works very well together. You can even have redundancy by having multiple upstream resolvers running on different ports (basically run the DNSCrypt Proxy daemon multiple times pointing to different public resolvers). I also use Firefox exclusively for my web browsing. By leveraging the tips on this page (https://www.privacytools.io/), you can lock it down to do a great job of privacy protection. The fact that your laptop's battery drain rate can be used to fingerprint your browser completely trips me out but hey – that's the world we live in.' What about the cloud you may ask? Well Brian has a nice solution for that as well: I recently decided I would try to live a cloud-free life and I'll give you a bit of a synopsis on it. I discovered a wonderful Open Source project called FreeNAS (http://www.freenas.org/). What this little gem does is allow you to install a FreeBSD/zfs file server appliance on amd64 hardware and have a slick administrative web interface for managing it. I picked up a nice SuperMicro motherboard and chassis that has 4 hot swap drive bays (and two internal bays that I used to mirror the boot volume on) and am rocking the zfs lifestyle! (Thanks Alan Jude!) One of the nicest features of the FreeNAS is that it provides the ability to leverage the FreeBSD jail functionality in an easy to use way. It also has plugins but the security on those is a bit sketchy (old versions of libraries, etc.) so I decided to roll my own. I created two jails – one to run OwnCloud (yeah, I know about NextCloud and might switch at some point) and the other to run a full SMTP/IMAP email server stack. I used Lets Encrypt (https://letsencrypt.org/) to generate the SSL certificates and made sure I hit an A on SSLLabs (https://www.ssllabs.com/) before I did anything else. His post then goes in to talk about Backups and IoT devices, something else you need to consider in this truely paranoid world we are forced to live in. We even get a nice shout-out near the end! Enter TarSnap (http://www.tarsnap.com/) – a company that advertises itself as “Online Backups for the Truly Paranoid”. It brings a tear to my eye – a kindred spirit! :-) Thanks again to Alan Jude and Kris Moore from the BSD Now podcast (http://www.bsdnow.tv/) for turning me onto this company. It has a very easy command syntax (yes, it isn't a GUI tool – suck it up buttercup, you wanted to learn the shell didn't you?) and even allows you to compile the thing from source if you want to.” We've only covered some of the highlights here, but you really should take a few moments of your time today and read this top to bottom. Lots of good tips here, already thinking how I can secure my home network better. The open source book: “Producing Open Source Software” (http://producingoss.com/en/producingoss.pdf) “How to Run a Successful Free Software Project” by Karl Fogel 9 chapters and over 200 pages of content, plus many appendices Some interesting topics include: Choosing a good name version control bug tracking creating developer guidelines setting up communications channels choosing a license (although this guide leans heavily towards the GPL) setting the tone of the project joining or creating a Non-Profit Organization the economics of open source release engineering, packaging, nightly builds, etc how to deal with forks A lot of good information packaged into this ebook This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License *** DTrace Flamegraphs for node.js on FreeBSD (http://www.venshare.com/dtrace-flamegraphs-for-freebsd-and-node-js-2/) One of the coolest tools built on top of DTrace is flamegraphs They are a very accurate, and visual way to see where a program is spending its time, which can tell you why it is slow, or where it could be improved. Further enhancements include off-cpu flame graphs, which tell you when the program is doing nothing, which can also be very useful > Recently BSD UNIXes are being acknowledged by the application development community as an interesting operating system to deploy to. This is not surprising given that FreeBSD had jails, the original container system, about 17 years ago and a lot of network focused businesses such as netflix see it as the best way to deliver content. This developer interest has led to hosting providers supporting FreeBSD. e.g. Amazon, Azure, Joyent and you can get a 2 months free instance at Digital Ocean. DTrace is another vital feature for anyone who has had to deal with production issues and has been in FreeBSD since version 9. As of FreeBSD 11 the operating system now contains some great work by Fedor Indutny so you can profile node applications and create flamegraphs of node.js processes without any additional runtime flags or restarting of processes. This is one of the most important things about DTrace. Many applications include some debugging functionality, but they require that you stop the application, and start it again in debugging mode. Some even require that you recompile the application in debugging mode. Being able to attach DTrace to an application, while it is under load, while the problem is actively happening, can be critical to figuring out what is going on. In order to configure your FreeBSD instance to utilize this feature make the following changes to the configuration of the server. Load the DTrace module at boot Increase some DTrace limits Install node with the optional DTrace feature compiled in Follow the generic node.js flamegraph tutorial (https://nodejs.org/en/blog/uncategorized/profiling-node-js/) > I hope you find this article useful. The ability to look at a runtime in this manor has saved me twice this year and I hope it will save you in the future too. My next post on freeBSD and node.js will be looking at some scenarios on utilising the ZFS features. Also check out Brendan Gregg's ACM Queue Article (http://queue.acm.org/detail.cfm?id=2927301) “The Flame Graph: This visualization of software execution is a new necessity for performance profiling and debugging” SSHGuard 2.0 Call for Testing (https://sourceforge.net/p/sshguard/mailman/message/35580961/) SSHGuard is a tool for monitoring brute force attempts and blocking them It has been a favourite of mine for a while because it runs as a pipe from syslogd, rather than reading the log files from the disk A lot of work to get SSHGuard working with new log sources (journalctl, macOS log) and backends (firewalld, ipset) has happened in 2.0. The new version also uses a configuration file. Most importantly, SSHGuard has been split into several processes piped into one another (sshg-logmon | sshg-parser | sshg-blocker | sshg-fw). sshg-parser can run with capsicum(4) and pledge(2). sshg-blocker can be sandboxed in its default configuration (without pid file, whitelist, blacklisting) and has not been tested sandboxed in other configurations. Breaking the processes up so that the sensitive bits can be sandboxes is very nice to see *** Beastie Bits pjd's 2007 paper from AsiaBSDCon: “Porting the ZFS file system to the FreeBSD operating system” (https://2007.asiabsdcon.org/papers/P16-paper.pdf) A Message From the FreeBSD Foundation (https://vimeo.com/user60888329) Remembering Roger Faulkner, Unix Champion (http://thenewstack.io/remembering-roger-faulkner/) and A few HN comments (including Bryan Cantrill) (https://news.ycombinator.com/item?id=13293596) Feedback/Questions Peter - TrueOS Network (http://pastebin.com/QtyJeHMk) Chris - Remote Desktop (http://pastebin.com/ru726VTV) Goetz - Geli on Serial (http://pastebin.com/LQZPgF5g) Joe - BGP (http://pastebin.com/jFeL8zKX) Alejandro - BSD Router (http://pastebin.com/Xq9cbmfn) ***

En este nuevo episodio de MrAnderson MD Mini les comento respecto a las renovaciones de los iPhone de mi familia, y del problema de NVRAM del MacBook Pro Mid 2012 de mi esposa Paola.

Back from WWDC and in the groove again, Dave and John talk through your questions and tips about upgrading your Mac's hard drive and RAM, NVRAM vs. EFI, static vs. dynamic IP addresses, and Dave shares a tip about the IR port on new Mac notebooks. Show notes for TMO […]