Dec 9 2021
Mar 22 2020
Mar 21 2020
Mar 7 2020
Feb 12 2020
Nov 25 2019
Nov 16 2019
Oct 7 2019
An alternative proposal for editing ISNs without involving the kernel:
Apr 5 2019
@Patrick What is the status of integration? Since we have kloak this is also a great defense to have. There is a script on there for packing as a deb:
Aug 7 2018
In theory, we could make sdwdate provide a local (default) (or optional opt-in server) NTP compatible time provider. Could be useful anyhow. -> sdwdate-server No idea how hard that would be.
And then configure NTP to connect only to that local NTP server.
Aug 6 2018
/usr/sbin/ntpdate as far as I know doesn't accept a command line command to take an offset (or anything). It connects to remote servers in its default design.
Yes, not readily accessible from command line.
The easy way: calculating the offset between local time and the onion average in timesync then using ntpdate's slew option if the offset is less than 0.5s. Otherwise you tell it to step up the time immediately so that you are accurately mimicking the default behavior. However you can force slewing all the time with -B. This way you won't need to touch kernel syscalls as ntpdate should be able to do the operation for you.
From what I understand, this code path is only relevant when timesyncd is talking directly with NTP servers and reacting to replies about deltas between local and remote times. There is no way you can call that function from the command line when using timedatectl standalone AFAICT.
Aug 5 2018
Jul 27 2018
Since we are interested in ntpd's default behavior (for blending in purposes) it turns out that it performs instant clock jumps once the delta difference is excessively large otherwise its slewing algorithm would take forever to adjust the time.
It doesn't seem that timedatectl supports gradual time adjustment. Our next best option is ntpd which can do so but cannot coexist with timedatectl - we can only run either but not both. According to popcon, ntpd is the mos widely used time daemon so its the natural choice.
Currently time is set using gnu date (clock jump) (initial run after current boot) or sclockadj (consecutive run) (slow clock adjustment).
Jul 25 2018
the time could be set with timedatectl by feeding it the time with this command:
sclockadj3 is done -> T686.
Jul 3 2017
A miracle has happened. All of https://github.com/yongboy/bindp/pull/6 was merged by upstream.
Very well. So finally they applied our patch.
Notified upstream. Let's see if he replies.
bindp pull request - security fixes, debian packaging, and more:
Jun 16 2017
@Patrick In the master branch the only difference in comparison to the original version that I can see is the main function at the bottom of the file. Did you not apply the changes? This code is still the previous one.
Merged into master.
Jun 15 2017
Jun 14 2017
Please create a new ticket for porting to some better C function.
adjtimex, as far as I can tell, is for tuning the clock to stay accurate. It's not directly for setting a new time. I assume it's used by ntp to speed up and slow down the clock, with more code that checks on it and stops it when it reaches the right time. Reimplementing this is beyond my skill.
Jun 8 2017
OK. It might strain my limited C knowledge, but I'll give it shot.
Jun 7 2017
Looks like at least NTP and chrony use ntp_adjtime/adjtimex
Where is adjtime being used in existing time sync applications? NTP?
Using adjtime would be a simple matter (of programming), but only has microsecond precision.
A popular existing linux tool.
Do we need precise control? The only requirement (other than working) is that it imitate an existing linux tool.
Jun 6 2017
adjtimex/ntp_adjtime looks quite complex, but also allow precise control on how time should be adjusted. From those two, according to manual page ntp_adjtime is preferred.
Jun 5 2017
It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.
I've left you some minor comments here: https://github.com/JasonJAyalaP/sclockadj/commit/e9bf84e3a400f7a8ef01e5f00dcefc013d0a9efe
What about using adjtime() syscall instead of all this? It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.
Jun 3 2017
@marmarek Would you be willing to review the C? It's under 75 total lines.
Jun 2 2017
I've rewritten the whole thing in C. It was a simple matter since we no longer need the random interval algorithm. Patrick prefers that it imitates ntpd instead of trying to hide.
Mar 26 2017
Mar 17 2017
Yes, sclockadj runs as root. Usually sclockadj is functional.
Mar 16 2017
the clock_gettime and clock_settime functions are passing zero as their first parameters and that means CLOCK_REALTIME. Firstly the process needs root privilege to touch real time clock, secondly you need to somehow run it by strace like:
TZ is unset since it's started as a systemd unit file.
The C code itself doesn't have any CPU intensive instruction, if the problem is really what is written as inline C, I suspect the issue is either with
Can't find what debian package ship debug symbols, there is no -dbg package there: https://packages.debian.org/source/stretch/ruby2.3
Ah, it's ruby... So, python-dbg is irrelevant, but trying gdb may still be a good idea.
Thanks for having a look!
I don't see any loop there and only very simple function calls, so I don't see how that would trigger such bug...
Mar 10 2017
Do you see any things a malicious application could to gain arbitrary code execution through bindp?
Mar 9 2017
Notified upstream. Let's see if he replies.
Functionally speaking, as I tested, it works great in Whonix. Pretty much done.
@Patrick Do you have anything else from this project remained that needs extra working on ?
Works for me!
Mar 8 2017
Onionshare 0.9.1 | https://onionshare.org/ [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged [!] connect(): AF_INET connect() call [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged [!] connect(): AF_INET connect() call [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged [!] connect(): AF_INET connect() call [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged Can't connect to Tor control port on port [9151, 9153, 9051]. OnionShare requires Tor Browser to be running in the background to work. If you don't have it you can get it from https://www.torproject.org/.
Added that. And added some intent style changes. Please tell me if my C intent style is actually making things non-standard / worse than before.
Why did you add #ifdef SO_REUSEPORT?
Well the segfault error is strange here, I must run it locally with your setup to check and debug which is not possible for now, but it's good you made it work finally. Good job Patrick. Still I think PIE related options are not needed for libraries.
I will modify the code by tonight and send the new revisions.
Mar 7 2017
It's functional! Successfully changes the listener IP.
That's great! Thank you for your help! Just now tested. Unfortunately it does not work.
@Patrick Nice, now regular testing needs to be done from your side, please keep in mind that connect function has to change as well, but before that I must assure that current bind() works properly and as expected. If everything goes well I will write whole code from scratch for you by modifying init and connect functions.
Mar 6 2017
What does DSO mean?
Can we have all hardening with PIE enabled as well as without ld warning?
But these warnings are not related to my revisions, they probably existed in original code.
@Patrick You can compile without -fPIE (I think -fPIC is enough):
Do you know how to fix these compiler warning?
one more stylistic fix:
@Patrick The reason that I inserted curly braces is that the first line after "case AF_INET:" is not syntactically a statement, to work around this you may use a dummy sentence or use braces like what I did. The break keyword can be inside that block; there is no difference.
I created a branch address-family-check to ease review.
Mar 5 2017
@marmarek If the problem is only with applications listening on both AF_INET and AF_UNIX,
@marmarek If the problem is only with applications listening on both AF_INET and AF_UNIX, I think the solution should be easy, we can change the bind function in a way that it only changes local address of the sockaddr_storage while the protocol family is AF_INET. For AF_UNIX address family there doesn't seem to be any need to change the address (the pathname of the socket). By applying these changes will the problem get solved? If yes, I will rewrite the bind function for you to test.
Feb 23 2017
The problem is not in connect function, but in bind. It assume AF_INET family, casting sk pointer to struct sockaddr_in. But if socket family is something different, the structure also may be different (for example struct sockaddr_un for AF_UNIX). In practice, besides misusing this library, the problem only applies to applications listening on both locak (AF_UNIX) and network (AF_INET) sockets. Because you don't use this library for AF_UNIX-only applications.