Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jeremy J Jedlicka
    @jjjedli_gitlab
    if this was a couple months old, then I could understand, this has been an issue for 16 YEARS
    metalefty
    @metalefty
    if the issue affects xrdp, another CVE should assigned to xrdp.
    It depends on context.
    Jeremy J Jedlicka
    @jjjedli_gitlab
    the CVE addresses an issue with Microsoft Remote Desktop Protocol, which according to http://xrdp.org/ , the very first line of the page, xrdp uses microsfot Remote Desktop Protocol. The fix is on the server you are going to RDP to, you need network level authentication. If xrdp is using microsoft's rdp and this is the solution, why does another cve need to be created? It states right in the CVE what is needed.
    metalefty
    @metalefty
    Protocol and implementation is different.
    yes NLA is actually needed. but not always necessary. and I'm not saying we won't implement NLA. any kinds of helps are welcomed.
    metalefty
    @metalefty
    More hands will make NLA earlier.
    BTW, The security of the entire system is not guaranteed by a single piece of software. It is sometimes achieved by the theory defense in depth.
    Jeremy J Jedlicka
    @jjjedli_gitlab
    So, putting our debate aside. I am not sure how to develop/impliment this so I cannot help with that. How to I get it on the radar and make it a higher priority task to be implemented in xrdp? Is there a ticket system? contact? someone to discuss it with to get someone prioritizing this fix when they have spare time to work on xrdp?
    metalefty
    @metalefty
    Many feedbacks will raise its priority. You're not the one who requested NLA we know NLA is wanted.
    Jeremy J Jedlicka
    @jjjedli_gitlab
    I understand that the entire system is not guaranteed by a single piece of software. We address all known security risks on all our systems and network devices. this just happens to be one of the risks that has been showing up for our organization right now that i have been trying to track down a fix for.
    metalefty
    @metalefty
    anyway, thanks for the push for the NLA feature request.
    Jeremy J Jedlicka
    @jjjedli_gitlab
    thank you for listening. I have security managers I have to answer to for our systems. This isn't just me, and I am sorry if I came off sounding negative. I was just trying to dig further and find out how we get this fix implemented for our organization.
    metalefty
    @metalefty
    xrdp is being developed 2 or 3 active developers now. @matt335672 is most active in recent a year. he joined xrdp project 1 or 2 years ago and he made an extremely a great contribution.
    He has already started to redesign authentication architecture. We can't promise when NLA will be ready because he's also a volunteer. However, it gets closer than before he joined.
    Jeremy J Jedlicka
    @jjjedli_gitlab
    thank you, it is progress I can put in my report.
    It is not directly related to NLA but an important redesign before starting NLA.
    Jeremy J Jedlicka
    @jjjedli_gitlab
    thanks again
    matt335672
    @matt335672

    Sorry I missed this over the weekend.

    @jjjedli_gitlab - I'll gloss over the discussion regarding Nessus. Your organisation has decided to use it, and regardless of whether you personally think that's a good idea or not, I can see you're in a position where that's not up for debate. I've been there myself as a syadmin in a previous life, so I understand your position.

    We're well aware we're missing NLA, but implementing it requires a significant change to the architecture. This in turn needs a good understanding of the use cases xrdp applies to, and how xrdp has changed over the years as Linux authentication in particular has evolved.

    Currently, xrdp consists of two processes. The xrdp process handles the incoming connection on TCP port 3389. Session management functions, including authentication are handed off to xrdp-sesman over an IPC mechanism we call SCP. SCP implements a basic 'one-shot' authentication where a username and password are passed from xrdp to xrdp-sesman, and a yes/no answer is returned. This is fine for simple usages, but not for more complex scenarios.

    One of the original xrdp developers was working on improving SCP, but for undisclosed reasons abandoned both the project and it seems software development mid-implementation. I've done some investigation into historical commits, and summarised what I've found on the wiki. It's a blow to any project when this sort of thing happens, but it's not uncommon.

    Essentially SCP has remained unchanged for well over a decade for reasons which I imagine you can now see. In that time, PAM has become mainstream, and there has been a lot more interest in integrating Linux with enterprise authentication systems, particularly AD.

    The plan I have is to replace SCP with something else which can run over the internal xrdp transport mechanism, but more easily support two-way authentication conversations. This is essential for full PAM support, NLA, auto reconnect and some other things I won't go into.

    I've kicked off https://github.com/neutrinolabs/xrdp/discussions/1961 for a couple of reasons. One is, I've been approached by an organisation which is considering sponsoring some of this work, and the other is that I don't want to do this all in my head, and then for reasons I can't foresee disappear off the scene as has happened in the past, before we've got a clear direction as a project.

    NLA is a way off I'm afraid. I'm focussed at the moment on getting the basics right. It's possible that with a better documented SCP, we may be able to get more developers working on this in the future. At the moment it's a poorly understood bit of the system.

    I hope that's useful. If you feel able, please contribute to https://github.com/neutrinolabs/xrdp/discussions/1961.

    matt335672
    @matt335672

    @metalefty - The NEWS Wiki page should be up to date for this release. I've just edited it to add the clipboard file transfer logging PR.

    I've also added an announcement to deprecate running xrdp and xrdp-sesman on different hosts, so that we are able to move to UDS for this interface maybe in the April 2022 or August 2022 release. Are you happy with that?

    1 reply
    matt335672
    @matt335672
    Any chance we can get neutrinolabs/xorgxrdp#186 merged in for the next release of xorgxrdp? Another issue it fixes has just been explored in neutrinolabs/xrdp#1964
    12 replies
    matt335672
    @matt335672
    I'll be away next week, and won't find it easy to connect. I should be back around the 20th or so, well before the release at the end of the month.
    metalefty
    @metalefty
    Let's wrap up PRs for an August release. No more new PRs will be merged except for critical bug fixes until the release. Existing PRs needs to be triaged whether to merge before the release or not.
    matt335672
    @matt335672
    Agreed.
    matt335672
    @matt335672

    The only two I can see that need to be discussed are neutrinolabs/xrdp#1692 and neutrinolabs/xrdp#1825. Is that right?

    1692 is currently tagged for 0.9.17 but needs a little work to be merged. Is that something we should push for? @Nexarian - what do you think about this one?

    I've added my thoughts about #1825 to the PR itself. It's a bit rough and could do with some more testing. On the other hand, the function it applies to doesn't work at all at the moment.

    2 replies
    Nexarian
    @Nexarian
    Also, some excellent news! Over the weekend Jay figured out how to get H264 encoding working on the GFX branch with NVENC encoding and Nvidia acceleration working such that the performance is absurdly good. We're talking the ability to play simple 3D video games in real time good (Probably not CounterStrike, but you get the idea). YouTube videos at 4k are easy now.
    1 reply
    I'm in the process of testing his branch and trying to add in my special sauce to make dynamic resizing work. It works except for sometimes when you resize the client crashes and you have to reconnect...
    metalefty
    @metalefty
    @matt335672 BTW, thank you for commenting on #1971. I'm not good at expressing my thoughts in English in contexts other than technical discussions. However, one of my basis is being/becoming a member, and volunteer is the shortest path to make project organization better. Before I joined xrdp project, release management was very poor. There was no explicit release cycle. That's why I volunteered to become a member of the project 5 years ago and I'm sure I contributed to xrdp in release management.
    metalefty
    @metalefty

    Some people worry and advise xrdp project organization. Of course, their comments are helpful and sometimes insightful. But few people actually help the project.

    Regarding project health, I think "release" is one of the biggest parts of indicating health.

    matt335672
    @matt335672

    That's a very good point.

    Having a proper release cycle helps to focus the mind and prioritise things. Yes, there are a lot of PRs open, but I'm hoping a lot of them can be cleared away when we get the authentication better, and when Jay and Nexarian get the GFX stuff merged.

    One of the things commented on in neutrinolabs/xrdp#1971 is the issue template. You raised neutrinolabs/xrdp#1574 a while ago, but we never got round to implementing it. Do you think that's worth getting done?

    2 replies
    manoj2patil
    @manoj2patil
    what bandwidth used for one session for xorg and xrdp ?
    matt335672
    @matt335672

    @nik:matrix.teckids.org - I've just had an automated message concerning xrdp and xorgxrdp being marked for autoremoval from testing (below)

    Is there anything I can do to help you resolve this in the best way?

    Thanks,


    xrdp 0.9.12-1.1 is marked for autoremoval from testing on 2021-10-10

    It is affected by these RC bugs:
    993096: xrdp: fails to migrate to testing for too long
    https://bugs.debian.org/993096

    This mail is generated by:
    https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

    Autoremoval data is generated by:
    https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

    1 reply
    metalefty
    @metalefty

    Nexarian> I wrote that line, though I wouldn't necessarily call myself an expert. I'm closer to a devoted fan who has debugged XRDP with lots of blood, sweat, and tears.
    https://github.com/neutrinolabs/xrdp/issues/1964#issuecomment-921331983

    I'm also a devoted fan of xrdp rather than an expert. I'm not an original author of xrdp however I just volunteered to join the xrdp project because release management was very poor as I said just above. I particularly work on release management, issue triage, negotiation with distro package maintainers (picking distro patches up) and I write codes a little bit.

    @Nexarian @matt335672 @aquesnel and other contributors are more experts than myself in writing C codes. I learn lots of things by reading the codes you wrote and code review.

    I suddenly just wanted to say thank you. Thank you always! Let me know whenever you want extra permissions on GitHub.

    3 replies
    buhtz
    @buhtz_gitlab
    Hello togehter. I have a simple question I couldn't find the answer in the docs.
    Does Xrdp use an existing user-session or does it create a new user-session?
    matt335672
    @matt335672

    You'll get a new session.

    If you want to connect to an existing console session, you'll need to use something like x11vnc to make the session available over the VNC protocol. xrdp can then connect to that session.

    Nexarian
    @Nexarian

    Wanted to let you all know what I've been up to recently!

    Jay created a new branch of the egfx prototype a few weeks ago that enables direct memory access to the Xsession such that when you're using hardware acceleration with Nvidia all processing is done on the card until the last moment when the memory is copied out to be shipped over the network. The speed is unlike anything XRDP has been capable of before. We're talking the ability to play full screen youtube videos in spite of 30-40 ms latency over a WAN connection. Using things like Blender and other photo editing is now a realistic option.

    I, true to form, have been working on adding resize-on-the-fly to it, and here's my prototype: https://github.com/jsorg71/xrdp/pull/6/files

    But I could also use your help. The xorgxrdp_helper module, defined here: https://github.com/jsorg71/xrdp/tree/egfx_helper/xorgxrdp_helper seems to have a weird bug. The logging will sometimes cut out in the middle of writing a line. It looks like this:

    [20210830-00:29:00] [INFO ] [xorgxrdp_helper_nvenc.c][78][xorgxrdp_helper_nvenc_init]:NvEncodeAPICreateInstance rv 0
    [20210830-00:29:00] [INFO ] [xorgxrdp_helper.c][172][xorg_process_message]:100 type 1 size 4
    [202

    As best I can tell the system is buffering, but I don't understand why. Logs are initialized here: https://github.com/jsorg71/xrdp/blob/egfx_helper/xorgxrdp_helper/xorgxrdp_helper.c#L443

    @aquesnel -- You're our logging expert, do you have any idea why this might be happening?

    matt335672
    @matt335672

    I can't see why this should be happening on a quick look.

    The log file should be opened by internal_log_file_open() in common/log.c. This specifies O_SYNC for writes.

    You could use a debugger to check the file is actually being opened here. Also, you're not using anything exotic for the filesystem you're logging to are you?

    Nexarian
    @Nexarian
    It's standard Ubuntu 20.04 and the .xorgxrdp.%s.log files are right next to it, so no, nothing exotic there.
    But good idea for debugging!
    I actually only recently figured out how to use VS Code Remote to debug XRDP
    Nexarian
    @Nexarian
    Though actually thinking about this more, this is done on startup. Any tips on how to attach a debugger to something when it just starts up?
    Nexarian
    @Nexarian
    Is it possible that the g_snprintf function is messing up the state of the FD?
    These lines are certainly interesting
    g_writeln("xorgxrdp_helper::xorgxrdp_helper_setup_log: using "
              "log file [%s]", log_file);
    if (g_file_exist(log_file))
    {
        g_file_delete(log_file);
    }
    matt335672
    @matt335672

    One way to attach a debugger to this is to add a busy-wait loop into the code. This is off-the-top-of-my head and not tested:-

     volatile int attached=0;
    
    static void wait_for_debugger(void)
    {
        while (!attached)
        {
            g_sleep(1);
        }
    }

    You can the attach the debugger, break, set the value of attached to 1, set other breakpoints, and off you go.

    I think the lines you've called out above are just to make sure the log file is empty when you start. Provided it's called in the right place that is.

    Nexarian
    @Nexarian

    I figured it out. It's due to my lack of understanding of arcane unix semantics. Jay had removed this: jsorg71/xorgxrdp@ef9dbe4

    Interestingly, those files he removed redirect the "execlp" STDOUT and STDERR output to those files. But those outputs weren't buffered properly.

    It's also due to the way I merged the code. Anyway, problem solved. XRDP logging works.