Re: Possible Security Hole in SSHD w/ CYGWIN?
David Willis writes: > So you're telling me any user that logs in using key authentication cannot > access the network as the same user (i.e. this is the intended behavior)? If > that's the case wouldn't it be better not to allow network access at ALL, > rather than allowing it as the service account that sshd is running as? You don't have access to anything beyond the machine you've logged into associated with that user account until you create a new logon session for that account on that machine and you need to have the password for this token to be created. The same thing happens if you leave a remote desktop session lingering for a day or so, you will then have to give your password anew since those tokens or rather the Kerberos tickets based on them will expire. If you don't do that, you are still logged into the machine in question and can do pretty much anything there as you are used to, but you are no longer authenticated for network access. > Again, so this is intended behavior when logging in with keys? And > furthermore you are saying the only reason that I have network access as the > cyg_server account is because it is a domain admin, and if it was not, there > would be no network access whatsoever? You could access whatever anybody could access who is authenticated locally or a machine that has joined the domain; that shouldn't be much. But anything requiring more specific access rights associated with your user account would be denied because you're not fully authenticated. > So if I am hearing this right, anyone using SSH with key authentication > instead of password authentication, has NO network access through SSH > sessions at all? That seems unlikely, but if that's the case then so be it. Either that (assuming that you can't use a share that everyone has access to, which is unlikely) or you'd use the "passwd -R" dance, which is iffy in it's own right and certainly not something that you should roll out to just about any machine. Plus all the users have to remember that each time they're changing their passwords they also need to do the "passwd -R" again on each machine they ssh into lest they lock themselves out pretty quickly. Another option is to use password authentication on the first login to each server, then start another sshd as that user from the session just established and then use that secondary sshd with public key login. The secondary sshd would probably have to be restarted after a certain time when the Kerberos tickets expire. > Yes you're right, it is not the one that ssh_host_config produces. > Ssh_host_config would create a SEPARATE local admin account on EVERY box its > run on. That is impractical to manage on a domain and not the setup I want. What you want to do can (and should) be done without giving cyg_server domain admin rights. It needs to be restricted as much as possible, given that it already has some very powerful capabilities. You haven't described the rest of the setup process for sshd on each box, so I won't comment on the practicality of using local accounts anyway. I am quite happy with using a local account since it allows me to give each cyg_server a completely random password that works on just that machine and nowhere else and doesn't need to be recorded anywhere after the services have been installed. > I can assure you I do understand the rights that cyg_server needs to > function, why cyg_server was made a domain admin and why I do not "go with > the default setup that ssh-host-config" provides". However stingy you felt my remark about your application of the domain admin right was, I keep insisting that you shouldn't use it in that way, even if it seems to do what you want. It also does lots of things you absolutely don't want. In fact, there should be no permanently active accounts with domain admin rights anywhere on your network if you care about security. https://technet.microsoft.com/en-us/library/dn487454.aspx https://www.beyondtrust.com/blog/best-practices-for-managing-domain-admin-accounts/ > The one thing I did not > understand was that authenticating with a key was NOT equivalent to > authenticating with a password. That's the whole point of https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview although it may seem somewhat long-winded. If you think that the documentation can be improved, I'm sure Corinna doesn't mind getting a patch. > I now understand that fact - I would now > suggest that in the documentation you explicitly point out that when logging > in w/ key auth, you have the rights on the network that cyg_server has. I > don't think that point is explicitly made in the documentation, and I don't > think it would be a bad idea to do so. That may actually be an unintended consequence of how Windows deals with the Kerberos tickets that govern network access and should be considered a bug. I'm not sure if or how that can be avoided, but it would be nice if sshd did not present those ticke
Re: Possible Security Hole in SSHD w/ CYGWIN?
Erik Soderquist writes: > I would suspect Domain Admin for the Cyg_server account is a > requirement of David's environment, which neither of us know anything > about at present. I know I've had to do things that were not "best > practice" due to corporate policy on more occasions than I care to > count. If that's the case, then security of the sshd is the least of your worries and I wouldn't install sshd at all. > Actually the Cygwin doc does include instructions for accessing > network shares when using ssh public key authentication. …which boil down to the password being stored (obscured) on the machine running sshd in order for sshd to obtain the necessary authentication via password-based login. > Once again, assumptions. While I can't explicitly vouch for David's > environment, as I do not have access to check, I can vouch for mine, > and mine was configured using sshd_host_config, with the only changes > after sshd_host_config being regarding TCP and X tunneling. I have to again make an assumption, namely that if cyg_server is a local account you've checked the C$ share of the same server that sshd is running on. That's bad enough, shouldn't happen and needs fixing, but at least you wouldn't be able to access any network shares from other servers that weren't otherwise accessible for everybody. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Cygwin-ports-general] cygwin/X error
On 14/02/2016 11:37, Girish Joglekar wrote: I installed cygwin and cygwin/X 64-bit on a Windows 10 laptop. I have an application that uses Motif and Xt libraries. It runs on Linux and Windows Vista with cygwin cygwin/X 32-bit. On Windows 10 I get segmentation fault. Here is a screen dump from gdb/where when it core dumps Inline image 1 Please help. I understand that everything is not yet ported to 64-bit. Please let me know what the timetable is. Will the updates be available through the cygwin-setup program or some other mechanism. Thank you. Girish #1 wrong mailing list : for this problem please use cygwin (at) cygwin (dot) com I set the reply-to there. #2 don't use screen dump. Use text. #3 Almost all packages available for 32bit are also available for 64 bit. The rest is obsolete stuff. Which application ? Is working in other 64 bit environment ? Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Vim and cursor position
To the maintainer, Yaakov, or anyone else who knows: Have the compilation options of Vim changed recently? Is there some other recent change that would cause the behaviour described below? Vim now appears to be remembering the last position of the cursor when you open files. I notice it most when running 'git commit', the cursor never starts on the first line but would appear to be where ever I ended the previous message. I find this jolly annoying. I would appreciate any insights people can offer. Thanks, James. signature.asc Description: OpenPGP digital signature
Re: mktemp() fails on Wine 1.9.3 + Cygwin 2.5.0-0.2
Greetings, Qian Hong! > Thanks a lot for testing Cygwin on Wine. > Wine Staging team and I done some Cygwin support work on Wine, we are > glad to see people using Cygwin on Wine! > However, generic speaking, if Cygwin works on Windows but breaks on > Wine, I believe the first place to report is the Wine project. You are > welcome to submit bug report to https://bugs.wine-staging.com/ and CC > me :) It's also a good idea to search msys2/cygwin before submit new > bugs: https://bugs.wine-staging.com/buglist.cgi?quicksearch=msys2&list_id=4821 > If any Cygwin developers are annoyed by Wine related post then I'll feel > guilty. > Regarding your specific problem, yes, I am able to reproduce it on > Wine, and I can confirm it works on Windows. > Could you file a bug to Wine Staging and CC me? I suggest to > investigate the Wine side first before bother Cygwin devs too much :) Pardon me for inserting my own noise, but there were cases, when running Cygwin under Wine, due to Wine's "generic" behavior some questionable Cygwin's behavior was uncovered. Thus, knowing there's a bug report is still useful. Just don't forget to report it to both sides and include reference links in your report. -- With best regards, Andrey Repin Sunday, February 14, 2016 19:31:09 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possible Security Hole in SSHD w/ CYGWIN?
On Sun, Feb 14, 2016 at 5:49 AM, Achim Gratz wrote: > Erik Soderquist writes: >> I would suspect Domain Admin for the Cyg_server account is a >> requirement of David's environment, which neither of us know anything >> about at present. I know I've had to do things that were not "best >> practice" due to corporate policy on more occasions than I care to >> count. > > If that's the case, then security of the sshd is the least of your > worries and I wouldn't install sshd at all. Again, not always optional if you are not the one dictating corporate policy. >> Actually the Cygwin doc does include instructions for accessing >> network shares when using ssh public key authentication. > > …which boil down to the password being stored (obscured) on the machine > running sshd in order for sshd to obtain the necessary authentication > via password-based login. Very true, but depending on the site configuration, there is at least arguably more security in the password being stored on the machine rather than passed across the network for the initial sshd connection. This is very open to debate, but that debate isn't the topic of this thread. The point of this reference was that yes, there are designs included to give network access to a user logged in via ssh using public key authentication. >> Once again, assumptions. While I can't explicitly vouch for David's >> environment, as I do not have access to check, I can vouch for mine, >> and mine was configured using sshd_host_config, with the only changes >> after sshd_host_config being regarding TCP and X tunneling. > > I have to again make an assumption, namely that if cyg_server is a local > account you've checked the C$ share of the same server that sshd is > running on. That's bad enough, shouldn't happen and needs fixing, but > at least you wouldn't be able to access any network shares from other > servers that weren't otherwise accessible for everybody. Valid assumption this time, yes I accessed c$ on the local host, though in my past experience, I would expect it to work on remote hosts as well in this scenario if the local and remote cyg_server account use the same password. For scripted installations across many hosts, I would expect them to have the same password. I can set this up to test and confirm it, but that will take a bit of time. Most of my stations are *nix already. I think the key point is that if no network password is stored using the "passwd -R" option, then there should be absolutely no network access at all in the current code/design, not a fall through to the cyg_server account's network access, regardless of how much or little network access that account has. -- Erik. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin_conv_path sometimes removes trailing slash
On 1/29/2016 10:21 PM, Ken Brown wrote: I'm using cygwin_conv_path to convert Win32 paths to POSIX paths, and I'm puzzled by the conversion d:/ --> /cygdrive/d without the trailing slash. Hi Corinna, After your recent patch (git commit 8b83da2), I now see the conversion d:/ --> /cygdrive/d/ as expected. But I have C: /c some_fs binary,posix=0 0 0 in my /etc/fstab, and I get the conversion C:/ --> /c I would expect conversion to preserve the trailing slash here too. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools
>> LLVM/Clang version bumps are time-consuming to get right. I actually
>> looked at 3.6, but MCJIT did not work OOTB with PE/COFF targets. I'll
>> have to see what the story is with 3.7.
>
> Understandable. 3.8 is in RC right now so maybe try building the
> release_38 branch if you get to it soon, otherwise wait a few weeks.
> I'm trying to figure out how to cross-build mingw llvm via cmake
> now that they've deprecated autotools (it's still there in 3.8 with
> a warning, but has been deleted on trunk which will become 3.9).
Okay, just FYI, building LLVM 3.8 or newer will fail with a win32-threads
build of mingw-w64 unless you build with LLVM_ENABLE_THREADS=0
and completely stub out lib/Support/ThreadPool.cpp. We're using MCJIT
(actually the new ORCJIT) in Julia and it's slower than the old JIT but
mostly works.
> I'll check your i686-libgit2 package soon, but I suspect it may be
> affected by https://github.com/libgit2/libgit2/issues/3342 and need
> to be built with -mincoming-stack-boundary=2
Confirmed.
$ echo '#include "git2.h"
void main() {
git_repository* repo_ptr = NULL;
char* repo_url = "https://github.com/JuliaLang/Example.jl";;
char* repo_path = "Example.Bare";
git_clone_options clone_opts = GIT_CLONE_OPTIONS_INIT;
clone_opts.bare = 1;
git_libgit2_init();
git_clone(&repo_ptr, repo_url, repo_path, &clone_opts);
git_libgit2_shutdown();
}'> clonetest.c
Tony@LAPTOP-O230JCFF ~
$ i686-w64-mingw32-gcc -L/usr/i686-w64-mingw32/sys-root/mingw/bin \
-lgit2 clonetest.c -g -o
/usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe
Tony@LAPTOP-O230JCFF ~
$ gdb -q /usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe
Reading symbols from
/usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe...done.
(gdb) r
Starting program: /usr/i686-w64-mingw32/sys-root/mingw/bin/clonetest.exe
[New Thread 8788.0x794]
[New Thread 8788.0x209c]
[New Thread 8788.0x638]
[New Thread 8788.0x123c]
Program received signal SIGSEGV, Segmentation fault.
0x6ccf9188 in libgit2!git_filebuf_commit ()
from /usr/i686-w64-mingw32/sys-root/mingw/bin/libgit2.dll
(be sure to `rm -rf Example.Bare` between runs of this test program)
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Vim and cursor position
On 2016-02-14, James Darnley wrote:
> To the maintainer, Yaakov, or anyone else who knows:
>
> Have the compilation options of Vim changed recently? Is there some
> other recent change that would cause the behaviour described below?
>
> Vim now appears to be remembering the last position of the cursor when
> you open files. I notice it most when running 'git commit', the cursor
> never starts on the first line but would appear to be where ever I ended
> the previous message.
>
> I find this jolly annoying.
>
> I would appreciate any insights people can offer.
Recent releases of the Cygwin Vim package (starting with 7.4.1179-1,
2016-01-29) have included Red Hat's or Fedora's /etc/vimrc, which is
loaded first when starting Vim. That file contains a BufReadPost
autocommand to do what you observe.
I don't like it, either, so I have this in my ~/.vimrc:
" Remove the (annoying) /etc/vimrc autocommand that positions
" the cursor " to the location it last had when the file was
" closed.
"
if exists("#fedora#BufRead#*")
au! fedora BufRead *
endif
if exists("#redhat#BufRead#*")
au! redhat BufRead *
endif
For Cygwin, you need only one of those, but I'm at home, my Cygwin
installation is at work, and I don't remember whether Cygwin uses
the Fedora or the Red Hat version of /etc/vimrc.
You may want to take a look at /etc/vimrc and see if it makes any
other settings you find undesirable and undo them in your ~/.vimrc
as well.
Regards,
Gary
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Vim and cursor position
Greetings, Gary Johnson!
> Recent releases of the Cygwin Vim package (starting with 7.4.1179-1,
> 2016-01-29) have included Red Hat's or Fedora's /etc/vimrc, which is
> loaded first when starting Vim. That file contains a BufReadPost
> autocommand to do what you observe.
> I don't like it, either, so I have this in my ~/.vimrc:
> " Remove the (annoying) /etc/vimrc autocommand that positions
> " the cursor " to the location it last had when the file was
> " closed.
> "
> if exists("#fedora#BufRead#*")
> au! fedora BufRead *
> endif
> if exists("#redhat#BufRead#*")
> au! redhat BufRead *
> endif
> For Cygwin, you need only one of those, but I'm at home, my Cygwin
> installation is at work, and I don't remember whether Cygwin uses
> the Fedora or the Red Hat version of /etc/vimrc.
> You may want to take a look at /etc/vimrc and see if it makes any
> other settings you find undesirable and undo them in your ~/.vimrc
> as well.
It may be worthwhile to do this only for certain names of files.
Overall, I find having editor remember where I have been in the code useful.
--
With best regards,
Andrey Repin
Monday, February 15, 2016 00:21:34
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools
On 2016-02-10 18:58, Yaakov Selkowitz wrote: (Also a newer clang+llvm would be useful, they've made a lot of improvements since 3.5.) LLVM/Clang version bumps are time-consuming to get right. I actually looked at 3.6, but MCJIT did not work OOTB with PE/COFF targets. I'll have to see what the story is with 3.7. FWIW, I have 3.7.1 ready pending a stable gcc 5.3.0 release. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Segmentation fault with openssh and pkcs11
Hello Cygwin Team As suggested by Achim, I've compiled opensc for cygwin. I used part of the build instruction from: https://github.com/OpenSC/OpenSC/wiki/OpenSC-Windows-installer, mainly: ./bootstrap && ./configure --disable-doc && make && make install. I can successfully run binaries that I've compiled this way and detect my smart card. When I run openssh with the pkcs11 libary I unfortunately still get a segmentation fault with: command: ssh -I /usr/lib/opensc-pkcs11.dll hostanme output: Segmentation fault (core dumped) What are your guys thoughts? Regards -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Vim and cursor position
On 2016-02-14 21:24, Gary Johnson wrote:
> On 2016-02-14, James Darnley wrote:
>> To the maintainer, Yaakov, or anyone else who knows:
>>
>> Have the compilation options of Vim changed recently? Is there some
>> other recent change that would cause the behaviour described below?
>>
>> Vim now appears to be remembering the last position of the cursor when
>> you open files. I notice it most when running 'git commit', the cursor
>> never starts on the first line but would appear to be where ever I ended
>> the previous message.
>>
>> I find this jolly annoying.
>>
>> I would appreciate any insights people can offer.
>
> Recent releases of the Cygwin Vim package (starting with 7.4.1179-1,
> 2016-01-29) have included Red Hat's or Fedora's /etc/vimrc, which is
> loaded first when starting Vim. That file contains a BufReadPost
> autocommand to do what you observe.
>
> I don't like it, either, so I have this in my ~/.vimrc:
>
> " Remove the (annoying) /etc/vimrc autocommand that positions
> " the cursor " to the location it last had when the file was
> " closed.
> "
> if exists("#fedora#BufRead#*")
> au! fedora BufRead *
> endif
> if exists("#redhat#BufRead#*")
> au! redhat BufRead *
> endif
>
> For Cygwin, you need only one of those, but I'm at home, my Cygwin
> installation is at work, and I don't remember whether Cygwin uses
> the Fedora or the Red Hat version of /etc/vimrc.
>
> You may want to take a look at /etc/vimrc and see if it makes any
> other settings you find undesirable and undo them in your ~/.vimrc
> as well.
>
> Regards,
> Gary
Thank you very much. For everyone's information: /etc/vimrc appears to
group things under "fedora".
P.S. Sorry about the double mail Gary.
signature.asc
Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Assorted MinGW-w64 toolchain libraries and tools
On Sun, Feb 14, 2016 at 11:43 PM, Yaakov Selkowitz wrote: > On 2016-02-10 18:58, Yaakov Selkowitz wrote: >>> >>> (Also a newer clang+llvm would be useful, they've made a lot of >>> improvements since 3.5.) >> >> >> LLVM/Clang version bumps are time-consuming to get right. I actually >> looked at 3.6, but MCJIT did not work OOTB with PE/COFF targets. I'll >> have to see what the story is with 3.7. > > > FWIW, I have 3.7.1 ready pending a stable gcc 5.3.0 release. 3.8.0 will be out in two weeks, might be a good idea to wait for that. Thanks, ismail -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
