>Kids find a security flaw in Linux Mint by mashing keys

Forum Forums General Other Distros >Kids find a security flaw in Linux Mint by mashing keys

  • This topic has 48 replies, 11 voices, and was last updated Jun 16-4:27 pm by marcelocripe.
Viewing 15 posts - 31 through 45 (of 49 total)
  • Author
    Posts
  • #51423
    Forum Admin
    Dave
    Helpful
    Up
    0
    :D

    BTW, would slimski need a hook to copy the Xsession file/session-names to the sessiontype variable in slimski.conf after each apt install so that the options are updated?

    That would need 99-update-slim copied and changed to 99-update-slimski, change the contents to

    // Automatically update antiX menus after installing a program
    
    DPkg
    {
    Pre-Invoke {"/usr/local/lib/desktop-session/desktop-session-slimski-update.sh --check-diff="set" ";};
    Post-Invoke {"/usr/local/lib/desktop-session/desktop-session-slimski-update.sh --check-diff="check" ";};
    };
    

    Then copy and modify desktop-session-slim-update.sh as desktop-session-slimski-update.sh to substitute references from slim to slimski. That file uses /usr/local/lib/desktop-session/desktop-session-file-locations and lib-desktop-session. desktop-session-file-locations would probably include an extra slimski_conf line to specify its location.

    Alternatively (maybe better?) the files could be changed to exclude specific naming to slim/slimski and be conditional, storing an array in desktop-session-file-locations for the differing configs. This may be more work than it is worth though and it may be easier to include separate packaging/versions to install if using slim vs slimski. I did not look into it with great detail; only trying to highlight where to look for modifications.

    • This reply was modified 4 months, 2 weeks ago by Dave.

    Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

    #51425
    Member
    marcelocripe
    Helpful
    Up
    0
    :D

    Hi Skidoo,

    I would like to thank you for the excellent work you are doing at Slim Ski.

    Having Slim translated will already be excellent for antiX and for all current users and new users.

    skidoo wrote:
    How / why would a virtual keyboard be put to use in a login screen context?

    A: The part of your question “How?”, I unfortunately do not know how to answer you. But, “why would a virtual keyboard be used in a login screen context?”, This I know to answer you through practical examples. The virtual keyboard would be needed when:

    A notebook / netbook has keyboard keys failing or no longer working.
    When, for some reason, the PS2 keyboard fails, the user will have to shut down the computer in the wrong way using the computer’s power button.
    In the example cited by @Xecure in the case of Tablet.

    I saw on YouTube videos two Linux distributions that have this virtual keyboard feature on the login screen, DuZeru Linux and Lubuntu. But to function the virtual keyboard on the login screen the mouse cursor needs to be operated on the login screen. But as you explained, slim doesn’t have this feature.

    Can the “Tab” key be used to access the username and password fields?

    I left the question above due to the following current situation of Slim in antiX 19.3: the computer operator typed the wrong username and pressed the Enter key, the cursor goes to the password field. There is no way to return to the username field to correct the typo. The computer operator will have to enter any password just to reset the blank fields and be able to return to the username field and type again.

    Thank you.
    marcelocripe
    (Original text in Brazilian Portuguese)

    ———-

    Olá Skidoo,

    Eu gostaria de agradecer por seu excelente trabalho que você está fazendo no Slim Ski.

    Ter o Slim traduzido já será excelente para o antiX e para todos os usuários atuais e para os novos usuários.

    skidoo wrote:
    How/why would a virtual keyboard be put to use in a login screen context?

    R: A parte da sua pergunta “Como?”, eu infelizmente não sei te responder. Mas, “por que um teclado virtual seria usado em um contexto de tela de login?”, isso eu sei te responder através de exemplos práticos. O teclado virtual seria necessário quando:

    Um notebook/netbook possui as teclas do teclado falhando ou que já não funcionam mais.
    Quando, por algum motivo, ocorrer uma falha no teclado PS2, o usuário terá que desligar o computador de forma errada através do botão de ligar o computador.
    No exemplo citado pelo @Xecure no caso de Tablet.

    Eu vi em vídeos do YouTube duas distribuições Linux que possuem este recurso de teclado virtual na tela de login, o DuZeru Linux e o Lubuntu. Mas para funcionar o teclado virtual na tela de login o cursor do mouse precisa ser operado na tela de login. Mas como você explicou, o slim não possui este recurso.

    A tecla “Tab” é possível de ser utilizada para acessar os campos nome de usuário e senha?

    Eu deixei a pergunta acima devido a seguinte situação atual do Slim no antiX 19.3: o operador do computador digitou o nome de usuário errado e pressionou a tecla Enter, o cursor vai para o campo senha. Não tem como voltar ao campo de nome de usuário para corrigir o erro de digitação. O operador do computador terá que digitar uma senha qualquer só para reiniciar os campos em branco e poder retornar ao campo de nome de usuário e digitar novamente.

    Obrigado.
    marcelocripe
    (Texto original em Português do Brasil)

    #51429
    Member
    skidoo
    Helpful
    Up
    0
    :D

    need a hook to copy the Xsession file/session-names to the sessiontype variable in slimski.conf after each apt install so that the options are updated?

    The short answer:
    The “auto-populate the list of available sessiontypes” feature is currently ‘closed, for remodeling’.

    In the ~b1, which seemed barely suitable for presentation yet, I uploaded in reaction to what I (probably wrongly) sensed as “okay, now quit talking and SHOW us something”. The detail of “will slimski be able to dynamically populate the list of sessiontypes?” has not been finalized. The 40 or so lines of notes-to-self inline commentary gitlab………cfg.cpp#L445 address the issue(s) surrounding this quoted question. (No, I’m not hinting that “you shoulda read the code in the source package”. I’m just foregoing the opportunity to copypaste those notes into this forum post.)

    #51430
    Member
    skidoo
    Helpful
    Up
    0
    :D

    Part of this post was drafted weeks ago, and was intended to explain how support of “localizations” can be achieved, using the existing version of SLiM. Well, partially (or mostly) achieved ~~ incomplete because a few of the SLiM message strings are hardcoded (e.g. “authorization failed”, “capslock is ON”).

    Because slimski utilizes the same “how” (leveraging the load order of multiple resource files), this still seem worth mentioning:

    At each launch, SLiM first initializes a datastore populated with option:value pairs read from a table of intrinsic defaults… then it reads slim.conf, replacing (overwriting) any pairs which are specified within the conf file. It subsequently reads slim.theme, again replacing (overwriting) any previously-populated pairs.

    app.cpp#L211

    cfg = new Cfg;
    cfg->readConf(CFGFILE);

    from the above, here are two takeaway details:
    — SLiM doesn’t care whether a given option was specified in the conf, or in the theme
    — the last-read, among any redundant declarations, “wins” (overrides/overshadows)

    Prior to distribution, the entire content of the intended default slim.theme
    could be appended to the foot of slim.conf… and, based on the runtime $LANG env var, symlinking or copy-into-place performed by a wrapper (or early boot) script could load the overlaid localized strings from the “theme” file.

    ^–> (weeks-later, skidoo wrinkles its nose and mutters “yuk. Conditional symlinking? awkward…”)
    _____________________________________________________

    slimski ~b1 shipped only a few “localized theme variants” (to demonstrate POC) and the content of each was a mishmash (hodgepodge?) of placeholder messagevar:string lines.

    The expected content of a “localized theme variant” in forthcoming slimski versions is a “wide open, for discussion” detail.

    My thoughts, so far: (Choose a number, for sake of example) If the set of translation strings contains 10 messagevar:string pairs, the content of each conditionally-loaded “localized” file could be as minimal as that ~~ only the 10 lines necessary to overshadow messagevars in the generic theme file. This “minimalistic” approach would enable central (one place) edits to the theme’s layout details (positions, font sizes, colors) and would involve tiny, non-cluttered, localized files in the as-shipped theme. A local sysadmin might, optionally, freely add additional lines to further customize//personalize one or more variants.

    #51432
    Member
    skidoo
    Helpful
    Up
    0
    :D

    How great a chore to support the choice of 62 “languages” offered in the boot menu?

    translate.google.com

    welcome_msg    mi sopa también está congelada 
    reboot_msg     por favor quita las rocas de tu cabeza
    . . . 
    #53879
    Member
    skidoo
    Helpful
    Up
    0
    :D

    BTW, would slimski need a hook to copy the Xsession file/session-names to the sessiontype variable in slimski.conf after each apt install so that the options are updated?

    That would need 99-update-slim copied and changed to 99-update-slimski, change the contents to

    // Automatically update antiX menus after installing a program
    
    DPkg
    {
    Pre-Invoke {"/usr/local/lib/desktop-session/desktop-session-slimski-update.sh --check-diff="set" ";};
    Post-Invoke {"/usr/local/lib/desktop-session/desktop-session-slimski-update.sh --check-diff="check" ";};
    };
    

    Then copy and modify desktop-session-slim-update.sh as desktop-session-slimski-update.sh to substitute references from slim to slimski. That file uses /usr/local/lib/desktop-session/desktop-session-file-locations and lib-desktop-session. desktop-session-file-locations would probably include an extra slimski_conf line to specify its location.

    Alternatively (maybe better?) the files could be changed to exclude specific naming to slim/slimski and be conditional, storing an array in desktop-session-file-locations for the differing configs. This may be more work than it is worth though and it may be easier to include separate packaging/versions to install if using slim vs slimski. I did not look into it with great detail; only trying to highlight where to look for modifications.

    eggshells here. There are some details at play which are beyond the scope of the slimski packaging.

    dpkg -S /etc/init.d/debian/slim
    ^—> nil. So I’m guessing this file is injected during build-iso

    I’ll provide a suitable equivalent of the above file in the debian directory of the source project;
    betatesters can (should/must) copy it into place ~~ it would be improper for the slimski package to install this file

    /usr/local/share/live-files/
    For permanent installation, 3 equivalent files (or filepaths, added to a manifest somewhere) will be needed here. The responsible package is ??? “remaster” or “antix-remaster” or “remaster-antix” I have lost track of whatis the correct packagename

    99-update-slim
    antixccslim.sh
    /usr/local/bin/slim-login
    /usr/local/bin/slim*
    ^–> it is improper for a display manager package to ship any of these antiX-specific ancillary files
    We have an opportunity to untangle (uncouple) them so that the display manager won’t need to be disturbed, version-incremented & repackaged each time one of these is tweaked.

    The slimski package will ship 4 themesets, named: default, ax, NONE(sic), and flat.
    Each of these demonstrates optionally-configured features (e.g. single vs dual username/pw “fields”).
    If added to antiX, I propose that the buildiso template or some other package would provide the
    themefiles (and would populate an additional subdirectory) for the theme specified in the antiX conf file.
    -=-
    Even the etc conf file can be provided by some other package.
    slimski can does check for the presence of (TBD) a slimski.conf.antix file
    loading that, if found, otherwise falling back to loading a generically-named conf

    edited, to clarify:
    It currently does first look for “/etc/slimski.conf.antix” (lowercase x). TBD means it’s an easily-changed detail, open for suggestions.

    edited, to amend:
    Perhaps contrary to debian policy ( which might suggest /usr/local/etc/ placement )
    slimski package will install /etc/slimski.conf
    and at runtime, will selectively load /etc/slimski.local.conf
    if present, instead of the “generic” conf file.

    • This reply was modified 4 months, 2 weeks ago by skidoo.
    • This reply was modified 4 months, 2 weeks ago by skidoo.
    #53881
    Member
    skidoo
    Helpful
    Up
    0
    :D

    The list of configurable options has ballooned to 176 total.
    Most of these you will never touch, will never use.

    This is the output from a “slimski -s -p ax” run that betatesters can expect:
    https://pastebin.com/vMHNRdgp

    An additional -z option is provided, and (in combination with preview mode, with or without -s) generates even more verbose output ~~ including a granular list of which options were (perhaps redundantly) specified in which file(s).

    Even if ~b2 doesn’t solve the “crashes on reboot” issue, immediately after installing (even without setting active during debconf) betatesters can “export LANG=” to alter the system locale between runs to confirm the selective loading of localized themefiles. In the ~b2, monoglot skidoo is shipping only 2 variants: en_GB and en_US. Betatesters will discover a template file in the theme directory. Load it into text editor and SaveAs nn__NN whichever locale variant you wish to create.

    Docs, docs, and more docs are provided, but I trust that editing the locale file will be straightforward. The template is currently only 20 or so lines long. To support a given language, only 12 messagestrings per locale beg immediate translation.

    One of the remaining tweaks on my roadmap is to finish “getting all the messages (e.g. capslock messagestring) off the panel, displayed onto the background instead”. If a tiny panel image is used, and a font size suitable for HiDPI… “poco de loco mono su capslocko esta bustedmiente ahora” cannot fit.
    _______________________

    edit to add (instead of “bumping” the topic):

    When launching any custom command / program which has been assigned to F2–12 keybind
    ( or has been assigned as the popfirst_cmd, tentatively slated for use by Xecure to launch xvkbd )
    slimski will “drop permissions” prior to launching (and detaching) the child process.

    The commands associated with “reboot, systemhalt, console, exit” are (as in SLiM) still launched via a system() call and remain, arguably, somewhat insecure. However, these are each, independently, now guarded by a configurable *_enabled option.

    • This reply was modified 4 months, 2 weeks ago by skidoo.
    #56220
    Member
    skidoo
    Helpful
    Up
    0
    :D

    “beta 2” is available for testing
    https://gitlab.com/skidoo/slimski/-/blob/master/slimski_1.5.0~b2_amd64.deb

    The program looks for “/etc/slimski.local.conf” and, if not present, falls back to loading “/etc/slimski.conf”.

    Via conf file, sysadmin can elect to separately enable/disable use of each “special username” (exit,systemhalt,reboot,etc).

    Four themes are provided for the purpose of testing.
    Within the themes/default directory, locale-specific themefiles are provided for all of the 62 LANGs offered in the antiX legacy boot menu.

    To test the autoloading of locale-specific theme variants (for example, Spanish)
    from within a desktop session, you can use the commandstring
    LANG=”es_ES.UTF-8″ slimski -p default
    and
    to test from boot, you can choose Spanish (or other) from the legacy liveboot menu, or manually append lang=yourlang to the bootline

    The included theme layouts are “sloppy” (careless x/y coordinates assigned for each of the message strings) but demonstrate that 5 “cust” message slots, with customizable {x/y position,color,fontface,fontattributes} are available.

    Additional configurable “F2–F12” slots are available for custom messages (and/or commands)

    If you want to use xvkdb virtual keyboard along with slimski, assign it (its executable path) to the “popfirst_cmd=” line within the slimski.conf

    The conf file contains verbose inline descriptions for most (if not all of) the non-theme-related available optoins. Separate documentation related to theming is installed to /usr/share/doc/slimski/

    Lessons learned:

    — The beta1 failure to load via initscript deamonmode was due to my presumption that the LANG env var already exists when the initscript runs. Nope, so the initscript (now) consults /proc/cmdline and sets the envvar if lang= was specified on the bootline.

    — A small (as seen in “default” theme) panel area cannot accomodate “locale-specific” messages. (consider: “Username” vs “nombre de usuario” ~~ the same, fixed, x-coordinate offset is not be suitable for variable-length strings.)

    — Initially, due to “significant differences in features and conf option names”, renaming the program seemed to me advisable toward precluding user confusion. However, the hardcoded name “slim” is entrenched in build-iso and in various antiX scripts spread across multiple packages.

    .
    The program+docs should stand (or fail) on their own merit. Any aspect of the program which does not “work as described” in the documentation is a reportable bug. Anything unclear in the documentation, or absent from the documentation, is a “documentation request”. I’ll push+announce further versioned builds if any significant issues are reported.

    edited to add:

    The packaged theme files (including localized variants) should be regarded as “placeholders”.
    It would be pointless to tweak the exact details and content of these
    until/unless
    testers find the program to be a suitable “working solution”
    and
    the antiX devs decide to use this program to replace the current SLiM

    • This reply was modified 3 months ago by skidoo.
    #56231
    Member
    Xecure
    Helpful
    Up
    0
    :D

    I will give it a spin during the week, but no real feedback until the weekend.

    #56246
    Member
    marcelocripe
    Helpful
    Up
    0
    :D

    Skidoo wrote:
    “Beta 2” is available for testing
    https://gitlab.com/skidoo/slimski/-/blob/master/slimski_1.5.0~b2_amd64.deb

    I looked at https://gitlab.com/skidoo/slimski/-/blob/master/themes/default/pt_BR.

    Are they texts translated by internet translators?

    Can I help with the translation adaptation?

    Thank you for making Slim translatable.

    marcelocripe
    (Original text in Brazilian Portuguese)

    ———-

    Skidoo wrote:
    “beta 2” is available for testing
    https://gitlab.com/skidoo/slimski/-/blob/master/slimski_1.5.0~b2_amd64.deb

    Eu olhei https://gitlab.com/skidoo/slimski/-/blob/master/themes/default/pt_BR.

    Por acaso são textos traduzidos pelos tradutores da internet?

    Eu posso ajudar com a adaptação da tradução?

    Obrigado por tornar o Slim traduzível.

    marcelocripe
    (Texto original em Português do Brasil)

    #61765
    Member
    Xecure
    Helpful
    Up
    0
    :D

    EDIT: I have uploaded the slimski theme translations to transifex, for anyone interested in checking (and fixing) the automatic translations (if available)
    https://www.transifex.com/antix-linux-community-contributions/antix-contribs/slimski-theme/
    At the end of the week I will fetch them all and update the files in the original slimski git project.

    • This reply was modified 5 days, 15 hours ago by Xecure. Reason: slimski-theme added to transifex
    #61791
    Member
    marcelocripe
    Helpful
    Up
    0
    :D

    Thanks, Xecure.

    I will download the file https://gitlab.com/antix-contribs/slimski/-/blob/master/doc/translations_TEMPLATE.txt and prepare the texts pt-BR.

    The “pt_BR.po” I reviewed it, when I complete the “translations_TEMPLATE_pt-BR.txt” I will send it along with the revised file “slimski_pt_BR_15-06-2021.po”.

    marcelocripe

    ———-

    Obrigado, Xecure.

    Eu vou baixar o arquivo https://gitlab.com/antix-contribs/slimski/-/blob/master/doc/translations_TEMPLATE.txt e preparar os textos pt-BR.

    O “pt_BR.po” eu o revisei, quando eu concluir o “translations_TEMPLATE_pt-BR.txt” enviarei junto com o arquivo revisado “slimski_pt_BR_15-06-2021.po”.

    marcelocripe

    #61792
    Member
    manyroads
    Helpful
    Up
    0
    :D

    In the old days, I used to do that for my devs. It was called “Chimpanzee testing”. 🙂

    Pax vobiscum,
    Mark Rabideau - http://many-roads.com
    "For every complex problem there is an answer that is clear, simple, and wrong." H. L. Mencken
    dwm ~Reg. Linux User #449130
    20 Jan 2021 ~ "End of an Error"

    #61804
    Member
    Xecure
    Helpful
    Up
    0
    :D

    I have uploaded the slimski theme translations to transifex, for anyone interested in checking (and fixing) the automatic translations (if available)
    https://www.transifex.com/antix-linux-community-contributions/antix-contribs/slimski-theme/
    At the end of the week I will fetch them all and update the files in the original slimski git project.

    #61805
    Member
    skidoo
    Helpful
    Up
    0
    :D

    >>> strings to a .po file

    {gasp}
    {gulp}
    but but… the program does not not parse//consider//consume “.po” files

    This is a one-time effort.
    The content of the (less than a dozen) set of default strings are unlikely to ever change.
    Months back, prior to announcing, I had (already) used translate.google.com to pre-populate most of the 60 -ish locale files. What remains is for interested parties to examine the strings for their locale(s) and say “Hey, that’s not quite right, or is unclear, or is crazy nonsense” and take the opportunity to contribute superior strings for their locale.

    Packaged as a beta, FOUR theme directories are installed.
    Switching between these enables interested testers to gauge the layout customization possibilities.
    Only the “default” theme directory is pre-populated with files containing localized strings.
    Post-beta, the package will probably install only the “default” theme directory (and the content from the others will be installed under /usr/share/doc, and can be manually copied into place if/when someone cares to experiment with theme customization).

    Encapsulating each localized set of strings into a compiled “.mo” file would stand as an “anti-feature” ~~ interfering with a sysadmin’s ability to easily edit theme content (including strings) on-the-fly. Repeated editing, tweaking, checking rendered layout and positioning (via “-p” preview mode) is essential while creating a customized theme.

    At the end of the week I will fetch them all and update the files in the original slimski git project.

    {whew, there’s light at the end of the tunnel}

Viewing 15 posts - 31 through 45 (of 49 total)
  • You must be logged in to reply to this topic.