[DNG] Ascii LVM Encrypted Issue
Hello All, I've run this test both on Hyper-V VM install and a dedicated hardware install using a Dell R210ii, and the results are the same. If I do a new install using ASCII and use the default full disk encryption with LVM option - everything goes good, until the initial first boot. Upon boot up no matter what I do key presses don't register and no way to unlock the disk. I am using a USB keyboard, and I’ve tried a couple different models and the keyboard and configs i’m using have been fine going as far back as Ubuntu 12.04. I will try this with a legacy PS2 device if I can track one down this week, but my guess is no USB support from the busybox side. Cheers, Mike -- Michael McConnell WINK Streaming; email: mich...@winkstreaming.com toll free: 877-GO-4-WINK x 7400 direct: +1 312 281-5434 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Error with upgrading Pi2 from Raspbian Wheezy to Devuan Jessie
On 13-06-18 19:42, Arnt Karlsen wrote: > On Wed, 13 Jun 2018 11:01:37 +0200, info wrote in message > <09b7eee9-cd24-4615-a9c0-8eb52c1c6...@smallinnovations.nl>: > >> I now remember (and checked) this is not a RPi 2 but the last RPi 1 B >> in my collection of Pi's. I should have known because my other >> (newer) Pi's are running Devuan Jessie and ASCII without any problem. >> >> Although i do have a backup i have adapted my sources.list to Raspbian >> Jessie and upgrading it seems to work. > ..you're upgrading your RPi 1 B to Raspbian Jessie, and not to > Devuan Jessie or ASCII??? > My intention was to upgrade Raspbian Wheezy to Devuan Jessie but as Greg noted this is not gonna work on a Pi 1 B. Because of the ARM6 with VF and not a real ARM7 chip. After realizing this I changed the apt sources.list to point to Raspbian Jessie. Which seemed to work but does not because the packages installed with ARMHF for ARM7 are not overwritten with the Raspbian version. So I have restored my backup and stay at Wheezy until i have a spare Pi 2 or 3 to replace this Pi 1 B. It does not do anything on the internet so the danger of no security updates is limited. Grtz. Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [SOLVED] Unable to "Load missing firmware from removable media"
Warning: Long report. The following report documents the Devuan netinst process on a Compaq C700 laptop with missing Broadcom wireless adapter firmware. As it turns out, and as I have surmised and suggested in an earlier post, Devuan has inherited a old bug from Debian[1]; One that was never fixed; only a work around was provided, but if you are persistent enough you can find it (stumble upon it?) in the haystack that is the internet concerning this issue for this particular setup. At least it is there! This took considerable persistent effort and some help from the dng list for which I'm very grateful. (Thank you fsr). For the Initiated/Veterans, the Debian Bug can be found here: (A listing is provided at the end of this report). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740503 The logical play-by-play account of these frustrating efforts follows (with embedded Mutterings). For those who might be annoyed by such details, you have been warned. The mutterings are directed at the software, not to any individual. I don't believe Devuan is responsible for what I believe are shortcomings. The Experience. After running the "Detect network hardware" step of the Devuan netinst, it states: "Some of your hardware needs non-free firmware files to operate. The firmware can be loaded from removable media, such as a USB stick or floppy." Muttering: Based the following experience, is it *really* the case that the firmware files are "non-free", OR, is it the case that they are simply missing? "The missing firmware files are: b43/ucode13.fw b43ucode13.fw b43-open/ucode13.fw b43-open/ucode13.fw" (sic. The names are repeated.) Does this reflect a weakness in the code? Muttering: (Speaking to the software) What's that fullpath again?? Do you not know? After all, you are the program(mer). I'm sure you know. Why not tell us. Why not now? "If you have such media available now, insert it, and continue." "Load missing firmware from removable media?" (select Yes after inserting the appropriate removable media containing the firmware file). Comment: Without going any further, at this point, from tty2, one can see that the /lib/firmware directory on the target system has not yet been created. Comment: At this point, from tty4, one can also see: "Broadcom 4311 WLAN found (core revision 13)" And: "b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please read [...everything there]." And: "Broadcom 43xx driver loaded [ Features: PNLS ]" Comment: From this we know that the Broadcom B43 driver module is already loaded into the kernel. Comment: If we execute the following cmd in the tty2 terminal, we have visibility to the [pci-id/chip-id] information for the wireless adapter. (This requires esoteric knowledge on the part of the un-initiated trying to install Devuan on their (only?, not so network-connected) computer for the first time.) lspci -vnn | grep Network Which returns: (On the Compaq C700) "Broadcom Limited BCM4311 802.11b/g WLAN [14e4:4311] (rev 02)" Comment: For additional description of the wireless adapter, execute the following: lspci -vnn -d 14e4: (the colon is req'd) (more esoteric knowledge required here.) Comment: BTW, from your OTHER NETWORK-CONNECTED COMPUTER, you will find that there is no firmware to download from the URL Specified. But, after some study of that page to determine what the page is all about (Muttering: Since there is no Clear Explanation at the top as to what one might expect to gain from having read it), and with the information from the previous commands, one can use the table on that page to confirm that the B43 driver supports the 14e4:4311 chip set. (Muttering: Hooray! That's very nice to know! BTW, Getting back to the issue at hand, where did you say that firmware file is? You remember? Your know, the ucode13.fw one that you asked for?). Finding the ucode13.fw file: >From searching the web, there are so many "ways" of obtaining the file in >question that it leaves the un-initiated's head spinning: (different distros >(mostly Ubuntu), multiple releases, different platforms, etc., and over a >number of years, has created a confusing haystack on the internet. I've obtained it from several places but they are not the same length. >From much study and searching, the most common and cleanest way to get at this >file is as follows: Background: It seems that Broadcom wrote their own device driver for their chip set. Instead of releasing their device driver software and its associated firmware as open-source, they made it proprietary. Its called "wl" or "sta". Their driver is (apparently) distributable. (This must also be true of its .o components.???) That driver has been reverse engineered to produce two device drivers: B43 and B43-legacy. (Broadcom's wl driver is missing some desireable
Re: [DNG] Xorg, choosing setuid vs. libpam-elogind and rant about security (was: Re: Jessie -> Ascii upgrade breaks X)
On Tue, Jun 12, 2018 at 10:49:35AM -1000, Joel Roth wrote: > Hi Andreas, > > And thanks for the explanations! > > Andreas Messer wrote: > > Hi Joel, > > dd> > On Sat, Jun 09, 2018 at 01:52:06PM -1000, Joel Roth wrote: > > > [...] > > > I have and use dbus apps on my system, However, as far as > > > I'm aware, none of these programs has root privileges. > > > > > > As the pam/dbus/elogind/polkit mechanism is capable of > > > handing out root authority, and as all software has bugs, I > > > think we _can_ anticipate that bugs that create security holes > > > will be uncovered in this stack. How much scrutiny did the > > > developers devote? Did anyone ever consider security at > > > through the whole stack? Probably the developers of each > > > component do consider security in their own code. > > > > I'm not sure but i think there is a miss-understanding here. Neither > > dbus, elogind or polkit hand out "root" to other processes. > > > > dbus is just a rather standarized IPC mechanism to allow for > > communication between different processes. > > I may have confused ipc with rpc. > > > Also to make > > system processes (running with root permission) to talk with > > desktop applications. Of course, depending on the particular dbus > > interface the system process provides and how it implements it, > > this might become an attack vector. But in my oppinion this is > > more an issue of the system process implementation and > > dbus api interface definition of that service than of dbus it self. > > > > polkit is some kind of authority which is used by many system > > processes to figure out if a particular user or process is allowed > > to invoke a (in most cases dbus) api of a (maybe system) service. > > Wether access is granted depends on particular rules and maybe > > system state - here comes the session management into > > play. Many of the rules include a "the user must be > > running an active local session" statement. polkit does not perform > > any actions, it just veryfies that something can invoke something > > and reports the result back. > > > > polkit can be backed by two different session management systems, > > either consolekit or logind. But some desktop environments rely > > on a particular one. > > > > elogind itself is one of these session management implementations > > (providing the logind interface) and it tracks the sessions. In > > addition it does some things to the cgroups of the user processes > > and other weird things - its based on systemd-logind. > > > > In order to run without root permissions the xorg xserver > > relies on the session management. I think (not fully sure about this) > > that the session management services can also prepare > > permissions of device files, e.g. granting access to drm files > > for the x-server. > > ISTR that vdev can give process-specific views of /dev, and > appears to offer a different, lightweight option in that direction.[1] > Not clear how much these overlap, pretty clear that vdev > doesn't have anything to say about cgroups. Thanks for the info. The cgroup thing, well I have no idea if that would be really needed to run a desktop system. I was surprised by this when seen the first time. I think system-logind (and in turn elogind) use it to figure out if a process belong to a particular session. system-logind can/will also set various limits while elogind does not as far as i know. While I can understand the session management usecase, I'm not sure if the other crap is really required, especially since there are exisiting solutions for cgroup management. > [...] > So, I'm looking into the security implications of setuid X, > and found this helpful explanation on stackexchange:[2] > >X11 apps run as a non-root user. However, on most platforms >the X11 drivers run as root, so they can access the display >hardware. This introduces the risk that a malicious app >might be able to exploit some security vulnerability in the >X11 code and use it to become root. This is a serious risk, >because X11 is a complex system with a tremendous amount of >code, and all it takes is one security vulnerability >anywhere in that code to make a privilege escalation attack >possible. This is indeed a concern. > >Enabling remote attacks. If I run X11 on my Linux machine, >does that make it easy (or possible) for remote attackers to >"hack" my machine? The answer is no. Remote attackers have >no way to access or talk to X11, so running X11 on my >machine does not make my machine insecure. Fun fact about this is, having Xserver run as non-root wont protect you either. There were some kernel/xorg combinations which suffered from an anoying bug in direct rendering manager - I did not fully understood if it was the xorg driver's fault or a kernel issue. This bug made the whole graphics system crash, crash that even the tty console was not usable anymore (only ssh).
[DNG] Starting a Devuan subforum at LinuxQuestions?
It looks like contact from a VUA would be needed to get a subforum for Devuan established over at LinuxQuestions: "...The process for this is covered in depth elsewhere, but if you know someone that is officially associated with the distro that is interested in participating here at LQ, do feel free to put them in touch." https://www.linuxquestions.org/questions/lq-suggestions-and-feedback-7/devuan-4175631820/ I think there is enough activity over at that site that it would be a good idea to establish a presence there. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Error with upgrading Pi2 from Raspbian Wheezy to Devuan Jessie
On Wed, 13 Jun 2018 11:01:37 +0200, info wrote in message <09b7eee9-cd24-4615-a9c0-8eb52c1c6...@smallinnovations.nl>: > I now remember (and checked) this is not a RPi 2 but the last RPi 1 B > in my collection of Pi's. I should have known because my other > (newer) Pi's are running Devuan Jessie and ASCII without any problem. > > Although i do have a backup i have adapted my sources.list to Raspbian > Jessie and upgrading it seems to work. ..you're upgrading your RPi 1 B to Raspbian Jessie, and not to Devuan Jessie or ASCII??? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] A message from Patrick J. Volkerding
On Tue, 12 Jun 2018, Jimmy Johnson wrote: > Devuan or Trinity can borrow anything they find useful from the current > tree. Well, we all have learned SO MUCH from Patrick's good work all our life: I think we can already consider Devuan borrows from Slackware. FTR: after early experiments on yggdrasyl and sunsite ftp mirror, slackware has been the first gnu/linux distro I've ever used as my main computing platform, besides having NetBSD on a laptop. I believe this is also the case for Katolaz and Nextime. Slackware is a lighthouse in the mist. It is our J.R. "Bob" Dobbs inspiring us to edify the Church of Subgenius.. so... Get Slack! ciao :^D ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Error with upgrading Pi2 from Raspbian Wheezy to Devuan Jessie
On 13-06-18 01:52, Gregory Nowak wrote: > On Tue, Jun 12, 2018 at 09:34:01PM +0200, info at smallinnovations dot nl > wrote: >> I am trying to update one of my older Pi's 2 from Raspbian Wheezy to >> Devuan Jessie and have this strange error message: > > Someone correct me if I'm wrong. Raspbian jessie is armel based for > compatibility with the rpi1, while devuan jessie for the rpi2 is > armhf based. You're trying to upgrade armel packages with armhf > ones, which results in the segfaults you're getting. I'm not sure > it's possible to migrate from raspbian to devuan on the rpi2. Devuan > does have an image for the rpi1, which means there are armel packages > in the devuan repository. However, I'm not sure what you need to do > with your sources.list to get armel architecture on the rpi2. > > Unless you made a backup before starting the upgrade process, I'd say > you're already up the creek without a paddle. I'd suggest backing up > what you need to save, and writing a fresh devuan jessie image to your > sd card, or do a debootstrap if you're adventurous, and understand > how to debootstrap a foreign architecture. Good luck. > > Greg > > Thank you Greg. I now remember (and checked) this is not a RPi 2 but the last RPi 1 B in my collection of Pi's. I should have known because my other (newer) Pi's are running Devuan Jessie and ASCII without any problem. Although i do have a backup i have adapted my sources.list to Raspbian Jessie and upgrading it seems to work. Grtz. Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
