Re: Using a Python script as a login shell
Hey this looks like a fun thing to play with, I like what you've done. I logged in and accessed it. Now that it's been some time since you announced it and it's still running, I guess it has had some testing already. I don't see anything wrong with what you have done after a quick look, it seems like you took some steps to secure it. If you care about security you want to think about defense in depth. Even if there don't appear to be ways for arbitrary filesystem or network access to happen, you have to consider the effect of bugs in your program and bugs in python itself. To protect against unwanted filesystem access, I suggest: * use a vm without anything else important on it * consider filesystem quotas * lock down the user as much as possible. Consider e.g. apparmor or selinux. Maybe consider containerization/capabilities inside the VM To protect against unwanted network access: * prevent all outgoing network connections from the VM using iptables/nftables (or whitelist any that are necessary) * again consider networking restrictions using apparmor or selinux. What level of protection is necessary will depend on the severity of impact in the case it gets hacked, and also your own level of conscientiousness. Also consider putting in some monitoring; monitor network bandwith and CPU usage at least (perhaps # of logins as well) and set up an alert if those go outside limits, so you get timely notification if something should happen. Have fun, Alex P.S. this brings to mind https://en.wikipedia.org/wiki/Russell_Coker#SELinux_Play_Machine, which is no longer operating. When you say "expose it to the internet via SSH", do you mean expose it to everyone (e.g. by publishing the pssword), or will there still be some restrictions on who can access it? If the former, you should be able to set up ssh without any password required. On 16/02/24 21:36, Ralph Aichinger wrote: Hello fellow Debianites! I want do do a custom CLI for a project, and I am quite happy with the Python cmd module. Aside from having a practically un-googleable name it is very nice, and does a lot with very little code. So far, so good. But: If I write a Python script with this module, and expose it to the internet via SSH, will hell break loose? So far I've done the following: 1. Put my script in /usr/local/bin/turtle (the canonical example in the docs is something with turtle), you can see the sourcecode of my script here: https://pi.h5.or.at/mockturtle.txt This script does absolutely nothing sensible, you can try it out by doing a ssh -l admin probe.aisg.at from a IPv6 capable host (sorry, no IPv4). The password is "admin". Any and all suggestions on stuff that is stupid and crazy from a security standpoint in this script are very much appreciated! 2. Then I put /usr/local/bin/turtle in /etc/shells 3. I added a user "admin" that has /usr/local/bin/turtle as shell 4. I added following stanza to /etc/ssh/sshd_config Match User admin X11Forwarding no AllowTcpForwarding no ForceCommand /usr/local/bin/turtle 5. In the script I tried to catch the Ctrl-C signal, so the interpreter does not give out too obvious error messages (that show what is going on behind the scenes). Is this enough to harden this setup against escaping into a shell or the full python interpreter, to do something nasty? Or is it completely crazy, because theere is some way to abuse a setup like this, that I have not found yet? TIA Ralph
selinux causing problems
Does anyone know how to disable selinux? I had selinux installed on this system a long time ago. Recently I believe apparmor was active (and therefore selinux not active). Today I upgraded to Debian 12. apparmor was preventing named (bind9) from running; whatever I did, it was denying read to a file (/usr/share/dns/root.hints). So I disabled apparmor by setting apparmor=0 on the boot command line. Now it seems that selinux is active again, and even when I try to set selinux=0 to disable it, it is still running and spamming the logs with messages like logrotate.service: Failed to read SELinux context of '/lib/systemd/system/logrotate.service', ignoring: Operation not permitted How should I disable selinux? I followed the suggestion in the man page (man selinux: To properly disable SELinux, it is recommended to use the selinux=0 kernel boot option). This does not seem to work. Any help greatly appreciated. Thanks, Alex # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 12 (bookworm) Release:12 Codename: bookworm # cat /proc/version Linux version 6.1.0-13-686-pae (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-686-pae root=/dev/mapper/main-root ro quiet apparmor=0 selinux=0 # sestatus SELinux status: enabled SELinuxfs mount:/sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: default Current mode: permissive Mode from config file: disabled Policy MLS status: disabled Policy deny_unknown status: denied Memory protection checking: actual (secure) Max kernel policy version: 33
Crossgrade instructions seem broken
I'm trying to crossgrade a bullseye system (from i386 to amd64). The machine is headless (with no graphical display and it's also difficult to access a console), so I'm doing it over ssh. In preparation I've switched from systemd to sysvinit (due to the warning on the crossgrade page), and also installed busybox-static:amd64 and have a "busybox ash" shell running (in case of trouble). I'm following https://wiki.debian.org/CrossGrading, but at the step: Crossgrade `dpkg` `tar` and `apt` I get: #apt --download-only install dpkg:amd64 tar:amd64 apt:amd64 Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apt : Conflicts: apt:amd64 but 2.6.1 is to be installed apt:amd64 : Conflicts: apt but 2.6.1 is to be installed dpkg : Conflicts: dpkg:amd64 dpkg:amd64 : Conflicts: dpkg tar : Conflicts: tar:amd64 tar:amd64 : Conflicts: tar E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. It seems like perhaps the bookworm version of apt has some extra restrictions about installing other arch binary packages, and won't even download them for me. This is pretty inconvenient. Does anyone know any force- or allow- that will persuade apt or apt-get to do this? I tried --allow-remove-essential. No luck. I'll continue using wget, dpkg and manual dependency resolution. Maybe someone has some clues for me? Thanks, Alex
Re: Installation on NBD in the newly released
A wishlist bug report against the debian installer pseudo package would seem to be an appropriate way to go. I would also like to see nbd support in the installer. I'm guessing it will be too late for bookworm, I tried that using the nightly installer and had a similar problem - nbd kernel module was available but no userspace tools. https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=d-i.debian.org;dist=unstable Thanks, Alex On 21/05/23 06:17, Tomasz Wolak wrote: On 5/20/23 19:49, Tomasz Wolak wrote: On 5/20/23 19:17, Stefan Monnier wrote: I will not go to further details here, anyone interested can go to: https://t-w.github.io/debian/2022/03/09/diskless_debian_11_pxe_nbd/ for details. Have you reported a bug about this? You might also get in touch with the maintainer of `nbd-client-udeb` since that package seems designed for your use case, so if it doesn't work well enough, they might like to know. Well, it is not a problem with nbd-client-udeb, it is a problem with the lack of it in Debian installer. And I am not quite sure if this is a bug or just an unimplemented functionality. Debian installer do not have a fully-fledged interface for configuring NBD, so this might be avoided for a reason, like not giving people something that might/does not work. My point is that I would like that it progressed a bit further so that, at least, using the console of the installation system, nbd device could be configured and used. The pieces I did proves that it does not require much (esp. that my changes could be just used to improve at least initrd in this matter; only adding nbd-client to the installer remains). So, I am not sure if reporting a bug is a right place. There is no particular package that I can point to... But contacting the maintainer of the nbd-client seems to be a good idea. I will do that. Thanks.
Re: repeat of previous question that has gone unansweredseveraltimes.
Printing on Linux is poor. CUPS is poor. It doesn't work for some (a lot?) of people. I have a Brother HL-L2300D printer. It is connected to my (Debian bullseye) workstation by USB. I have CUPS installed. My printer prints sometime. Other times, it spins up (makes a noise like it is about to start printing), but nothing comes out. I can't get any useful diagnostics to tell me where the problem might be. My parents, who live some distance away have an HP inkjet printer. It works sometimes. Other times it doesn't. I get it set up so it's working and it might work for a while, but it will stop working for no reason. There might be several queues for the printer; some work and some just don't. A working queue will stop working for no discernible reason. Working queues will disappear, new queues will appear seemingly at random. The print system will default to an automatically provided queue that could never work, because it relies on some software component that is not installed etc... etc... Between my parents and my own system, I have spent 10s or 100s of hours trying to get a reliable printing system over decades, with many different printers. Maybe there were periods where printing worked OK. But I haven't managed to achieve reliable printing in the medium term. I read ESR https://www.catb.org/~esr/writings/cups-horror.html, and my personal experience is that nothing much has changed in the "driverless" era. I've been a sysadmin for 30 odd years, configuring different aspects of linux (webservers, email servers, DNS, networking, desktop environments etc.) using open source software. Some problems are difficult to solve, but I've always found that having a good basic understanding, checking logs, using tools to confirm what is happening, and doing research on how things work, allows me to solve those problems eventually. Not so with CUPS and printing. I have tried many different approaches (e.g. * reinstall from scratch, accept the default packages and default options. * go to the linux printing site and follow the recommended method for my model of printer * try to understand how CUPS works, set up as statically and simply as possible, and use standard tools to troubleshoot printing failures.) I have not succeeded with any approach. It could be that I have struck certain models of printer with bugs. Hardware and firmware bugs exist, and not just in printers. However, I don't find hardware or firmware bugs cause me significant pain as there are normally software or configuration based work-arounds/allowances for them in Debian. Except for printers. These same printer models work much more reliably in MacOS and Windows. Back in the lpr/lpd days things were more reliable. Is there a deeper problem affecting printing on linux? I asked work colleagues and got two responses: "oh, shit. you’re actually printing from linux. my condolences.', and "I use Epson and Ubuntu, never had an issue with print over IP - so I can attest to drivers working from that perspective atleast" My perspective is that there is a significant issue, at least for a portion of users. Implying the user is at fault (which Brian isn't necessarily doing here,) or acting surprised when someone has trouble printing, is like gaslighting. Maybe it works OK for you, but please understand that is not the general case. Debian can't support every printer for every user, but knowing that, CUPS should come with a health warning: "We supply this software as-is in the knowledge that it has known faults, and will not work reliably for all users. We wish there were a way that Debian users could reliably print, but there is not. You may get some help on Debian User, but in general printing is not supported." Thanks, Alex On 6/05/23 05:45, Brian wrote: Your conclusion is that the printing system is in itself is defective and that is reflected in your response.
Re: questions about cron.daily
See man crontab.
There are 2 ways of maintaining your crontab:
crontab [ -u user ] file
...
The first form of this command is used to install a new crontab from
some named file
I.e. you can keep a file in your home directory (or anywhere,) update it
and install it when changed using "crontab filename". This is
especially useful if you keep your home directory under version control
and want your crontab under version control as well. But I guess hardly
anyone does this.
The second way:
crontab [ -u user ] [ -i ] { -e | -l | -r }
...
The -e option is used to edit the current crontab using the editor
specified by the VISUAL or EDITOR environment variables. After you
exit from the editor, the modified crontab will be installed automati‐
cally.
I believe it actually causes the current crontab to be copied to a
temporary file, where is edited, then it is installed after a successful
editing session and the temporary file is deleted.
Like others, I've hardly ever met people who do things the first way,
but it likely was the original way of doing things.
Thanks,
Alex
On 7/04/23 17:08, to...@tuxteam.de wrote:
On Thu, Apr 06, 2023 at 06:54:31PM -0400, Greg Wooledge wrote:
On Thu, Apr 06, 2023 at 05:45:08PM -0500, David Wright wrote:
Users (including root) write their crontabs anywhere they like,
typically in a directory like ~/.cron/.
Is that... normal? I can't say I've ever seen anyone keep a private
copy of their crontab in their home directory like that.
It's news to me, too. I olny knew about the /var/spool/cron/crontabs
location.
Cheers
Re: exif --remove not idempotent, and a Debian man page bug
On 24/09/22 03:32, Greg Wooledge wrote: On Fri, Sep 23, 2022 at 11:22:31AM -0400, The Wanderer wrote: 'man bash' cites Brian Fox and Chet Ramey as the authors, and gives an E-mail address for each. (It's possible that they may be the active upstream maintainers, as well.) Chet Ramey is the current upstream bash maintainer. Brian Fox has not been involved with bash development for decades. Nevertheless, removing Brian's email address from the AUTHORS section is neither necessary nor desirable. Everyone knows it's a historical section. I've been using Debian as my main OS since 1997 or earlier. I've spent 100s of hours reading man pages. Although it's a reasonable assumption (since there are a lot of man pages with outdated AUTHORS sections), I didn't know the AUTHORS section is supposed to be an historical record. Have you got a reference to that somewhere? After all (some) man pages have a HISTORY section for historical information. In the case of the bash(1) page, it's actually followed by a BUG REPORTS section, telling you how to submit bug reports to the upstream maintainer. That's not common in man pages, but clearly not unheard of either. As a Debian user, however, one is expected to know how to file bug reports correctly. It is NOT done by trudging through the man page looking for the first email address one can find. It's done by using the reportbug tool, or by following the instructions on the <https://bugs.debian.org/> web site. Again, I sometimes report bugs to Debian and sometimes to upstream, and occasionally email maintainers directly, especially if I can't work out if any upstream still exists and especially if the software is not (any longer) in Debian. How is it expected that a new user will have learnt "how to file bug reports correctly?" What is the typical path for a Debian user to pick up that knowledge? What even is the correct way to report bugs, and where is that documented? I see https://www.debian.org/Bugs/Reporting, which mentions "Don't file bugs upstream, if you file a bug in Debian" Perhaps you can point to some documentation discussing whether to report a bug to Debian or through other channels. Or perhaps a statement recommending (particularly newbies) to report all bugs direct to Debian. It seems to be implied, but I didn't see where it was stated explicitly. I see at https://www.debian.org/support, that after IRC, this list is the second channel mentioned for people seeking support with Debian. I believe using phrases like "Everyone knows it's a historical section." when the OP didn't seem to know that, and "one is expected to know how" is not particularly helpful. Especially on the channel that is the first (usable) point of contact for new users seeking support, if they are not familiar with IRC. Greg, I'm wondering if you would consider using more friendly and inclusive language on the debian-user list? So that it's less off-putting to newbies (in general, regardless of whether the OP is a newbie.) In relation to man pages, perhaps everyone could agree that ideally historical email addresses could be removed from the AUTHORS section and moved to a HISTORY section. I'm sure we can all agree this should not be mandatory, but those who feel most strongly about it could contribute patches... -- Thanks, Alex King
Re: Firefox 104 on Sid unusable because it blanks open tabs after a few minutes
A couple of FF Extensions you might benefit from: Auto Tab Discard: although it does the opposite of what you want, (I.e. the purpose is to discard or "unload" tabs,) it gives a UI into the settings for when tabs are discarded. (Although I'm on FF 91.13.0esr, and I don't know if it works on FF 104.) Textarea Cache: Allows to save automatically the content in a text input field. Great for retrieving text you wrote into a website, e.g. if the submission failed for some reason. Not sure if it stores text from text input fields on discarded pages or not... Thanks, Alex On 8/09/22 05:10, debian-user-digest-requ...@lists.debian.org wrote: Subject: Firefox 104 on Sid unusable because it blanks open tabs after a few minutes From: Eike Lantzsch KY4PZ Date: 8/09/22, 04:16 To: debian-user@lists.debian.org I admit that I usually have ~ 70 tabs open. FF does not blank all, just most of them. Then I have to reload the pages and enter all information again if the pages contain forms like snail-mail tracking, tracking of packages, tracking of processes with the local communications state agency, following geomagnetic storms, RF-Propagation, blogs etc etc. My time is too valuable to waste it reloading and reloading web pages again and again. It happens with dynamic pages and with static pages. There is no consistency at all. I looked into the FF settings for a setup - but no - there is nothing about this behaviour. OK, so which browser will I now use instead of Firefox? have a nice day Eike -- Eike Lantzsch KY4PZ
Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?
nd closeness to the hardware. If you really want a language that lets you access the machine at the lowest level while allowing some modern high-level language constructs and a reasonably comprehensive standard library, you should learn Rust. It's not a language targeted at beginners, though. In terms of difficulty of learning between C, Python and Rust, I would say Python is the easiest, C would be in the middle and Rust the hardest. However both Python and Rust have active communities who will help learners. You probably wouldn't be the first novice to attempt to write an OS kernel as your first serious project, but in the unlikely event that you succeed you probably would be the first. In other words writing an OS kernel is not a great first project for a novice. If you want to be a good programmer (you would need to be to write an OS kernel), you should learn several languages. If you insist on learning only one and you want to be able to program OS kernels and device drivers as well as higher level tasks, then you should learn Rust. But Python is a more practical staring language as a novice, and you can move to Rust later. And yes some AI might take over all programming tasks one day, but I think there are still some more years for human programmers. I love programming, it is not a chore. So I'd still do it even if a machine could do it. But more likely AI will produce tools, and the best programming will still be done by humans with AI tools to help them. Cheers, Alex King
