Re: [DNG] Review of documentation needed

[golinux]

On 2021-09-16 22:30, goli...@devuan.org wrote:


You can find the docs that need reviewing here:
https://www.devuan.org/os/documentation/dev1fanboy/

All releases

General information
Installing Devuan
Full disk encryption
Network configuration
Devuan without D-Bus
D-Bus free software
Minimal xorg install
Minimal XFCE install



I just realized that several of those documents are already updated for 
Chimaera. Duh . . . Here's the new list:


General information (will need to be updated to Chimaera at the least)
Devuan without D-Bus (is this still possible?)
D-Bus free software (quite possibly out of date)
Minimal xorg install
Minimal XFCE install

Anything no longer useful/relevant will be removed.

Thanks for your feedback!

golinux

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Fwd: Upcoming compatibility problem of oldstable (and older) vs. certificates from Let's Encrypt

[Bernard Rosset via Dng]

Hello Adrian,


The issue has been recently resolved by the LTS Team, see LTS Advisory
DLA-2761-1 an DLA-2760-1. [1]


It seems that OpenSSL problem is merely addressed by DLA-2761-1; 
DLA-2760-1 deals with another package.



As far as I can tell, the reported issue on Debian-LTS List is also relevant
for Devuan jessie, ascii and beowulf.


As far as I can tell, there is no v1.0 of OpenSSL in beowulf, as the 
transition between v1.0 & v1.1 was done in stretch (ascii).


Moreover, that problem could only arise in stretch (ascii) if the TLS 
certificate agent was/is running against OpenSSL v1.0 and not v1.1; if 
the agent has been updated in the past 4 years, it was probably not the 
case anymore... and if it wasn't updated in the past 4 years, why are 
people even using that anymore? (o:


Thanks for the piece of information, though.
Bernard (Beer) Rosset
https://rosset.net/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] May I use Netaid source as an example of good code?

[aitor]

Hi,

On 19/9/21 10:31, aitor wrote:
_Note 4_: i've done a lot of improvements in the daemon (snetaid), but 
i still didn't push them to gitea. I'll let you know.


Done:

https://gitea.devuan.dev/aitor_czr/snetaid/src/branch/master 



Another clarification: readme files aren't updated.

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Fwd: Upcoming compatibility problem of oldstable (and older) vs. certificates from Let's Encrypt

[Adrian Zaugg]

The issue has been recently resolved by the LTS Team, see LTS Advisory 
DLA-2761-1 an DLA-2760-1. [1]

Thanks to the LTS Team!

Regards, Adrian.

[1] https://www.debian.org/lts/security/

In der Nachricht vom Thursday, 9 September 2021 17:50:57 CEST schrieb Adrian 
Zaugg:
> Dear List
> 
> As far as I can tell, the reported issue on Debian-LTS List is also relevant
> for Devuan jessie, ascii and beowulf.
> 
> Regards, Adrian.
> 
> 
> --  Forwarded Message  --
> 
> Subject: Upcoming compatibility problem of oldstable (and older) vs.
> certificates from Let's Encrypt
> Date: Thursday, 9 September 2021, 17:31:49 CEST
> From: Stefan Huehner 
> To: debian-...@lists.debian.org
> Message-ID: <20210909153149.gf6...@huehner.biz>
> 
> Hello LTS Team,
> 
> I want to raise a (rapidly) upcoming compatibility problem affecting older
> debian release when connecting via i.e. https:// to any system using SSL
> certificates from Let's Encrypt.
> 
> Raising here as i didn't see any discussion in debian project.
> 
> The problem:
> - Starting 2021-10-01
> - openssl < 1.1.0
> - gnutls < 3.6.14
> 
> will fail to validate any Let's Encrypt SSL certificates (which did not do a
> per-certificate choice to avoid this).
> 
> This article by the project has all the details:
> https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for
> -let-s-encrypt-certificates/143816
> 
> In short:
> - They use a certificate chain containing a CA certificate expiring on
> 2021-10-01
> - While that path it not valid after that date, there is alternative path
> still being valid
> - However older version of some libraries do not even try alternative paths
> but give up on seeing the expired one
> 
> In Ubuntu they are backporting the chances to avoid this problem in both
> openssl / gnutls:
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 (openssl)
> https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648
> (gnutls)
> 
> Given the wide-spread use of Let's Encrypt it may make sense to consider
> doing that also on the debian side.
> 
> Note that apt itself is using gnutls.
> So if people are using https:// to access some repos and the repo/mirror
> uses Let's Encrypt that could get much more annoying.
> 
> Checking openssl / gnutls versions across releases:
> jessielibssl1.0.0 1.0.1t
>   libgnutls-deb0-28   3.3.8
> 
> stretch   libssl1.0.2 1.0.2u
>   libssl1.1   1.1.0l
>   libgnutls30 3.5.8
> 
> busterlibssl1.0.2 1.0.2u
>   libssl1.1   1.1.1d
>   libtnutls30 3.6.7
> 
> bullseye  libssl1.1   1.1.1k
>   libgnutls30 3.7.1
> 
> Bug present in
> - openssl < 1.1.0
> - gnutls < 3.6.14
> 
> Looks like:
> - bullseye is fine
> - But every older release seems to be affected
> 
> Assuming there is interest this affects probably
> - LTS Team
> - ELTS if any of the sponsors is interested
> - 'normal' debian for old-stable ?
> I just wrote just here for the moment to not spam several teams.
> 
> Let's Encrypt offers alternative chain avoiding this bug but breaking
> compatibility with old Android. That can server as a workaround for this
> issue on case by ase. But as this is on the 'other side' (each certificate)
> not really a global fix.
> 
> Regards,
> Stefan Hühner
> 
> p.s. Please CC me on replies, i am not on the list
> 
> 
> -


signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] May I use Netaid source as an example of good code?

[aitor]

Hi,

On 2/8/21 11:41, aitor wrote:

On 2/8/21 0:44, aitor wrote:
Better said, the suid binary can check whether or not the gui has 
handled the signal as expected because
the default behavior of SIGUSR1 (User defined signal 1) is to 
terminate the process. See the table at the

end of the link:

https://en.wikipedia.org/wiki/Signal_(IPC)#POSIX_signals 



I.e., when such a intruder is acting the 
PSTAT_BINARY="SOMEWHERE_DEFINED_NAME" with process ID="PID"

no longer exists.


Here you are the code:

https://www.gnuinos.org/suid/ 


** HOWTO: **

1) Install Jude Nelson's libpstat:

$ git clone https://github.com/jcnelson/libpstat.git
$ cd libpstat
$ make OS=LINUX
$ sudo make install PREFIX=/ INCLUDE_PREFIX=/usr


2) Open an empty directory and download the files:

$ wget https://www.gnuinos.org/suid/Makefile
$ wget https://www.gnuinos.org/suid/gui.c
$ wget https://www.gnuinos.org/suid/suid.c
$ wget https://www.gnuinos.org/suid/intruder.c


3) Install libgtk-3-dev:

$ sudo apt-get install libgtk-3-dev


4) Build the files:

$ make


5) Run the GUI in the command line and click on the button several times:

$ ./gui

You'll get:

From GUI: Received a 10 (SIGUSR1) signal sent from the suid
From SUID: Ok, go on!


6) Open a new tab in the command line and run the intruder (the GUI 
remains running):


$ ./intruder

You'll get:

Foreign PID to use: 4301
From SUID: Stop, you're an intruder!

If you have a look at the code of both programs, they're trying to do 
the same (using the intruder a foreign pid).
Keep in mind that, for our testing purposes, all the binaries must be 
located in the same directory, since

we're using:

key_t key = ftok(".", 's');

to access the same shared memory segment.

Cheers,

Aitor.



There is a better way to do all this because it's possible to enquery 
the sender of the socket thanks to getsockopt(),

doing something like this:

pid_t pid;
socklen_t pid_size = sizeof(pid);
rc = getsockopt( df, SOCK_STREAM, SO_PEERCRED, , _size );
 if (rc == -1) {
 perror("getsockopt");
 return -1;

}
printf("client pid=%d\n", pid);

where fd is the file descriptor tied to the unix socket.

Once we know the pid of the process, libpstat will give us the fullpath 
to the binary runin the process,
checking afterwards whether or not it's included in the *white* list of 
allowed applications.


On the other hand, as simple-netaid is actually daemonized, it's 
possible to run all the stuff requiring root
permissions though the service, so i decided to remove the suid binary 
providing to the shared library
the CAP_KILL linux capability instead [*], which will allow us to send 
signals to the daemon without the requirement of
root permissions. Yes, to the shared library! Because doing this way, we 
don't need to give capabilities to each
application depending on it... [**]But i'll explain shortly this point 
in another thread headlined: "Hopman,

Simple-netaid and Linux capabilities".

Cheers,

Aitor.

_Note 1_: giving suid permissions to an executable shared library 
doesn't take effect (and it wouldn't be recommended),

but it's possible to provide them linux capabilites.

_Note 2_: keep in mind that the shared library sends the signal to the 
daemon, and then the daemon communicates with
the running process though the socket filtering possible intruders in 
the client side (the shared library cannot make use
of libpstat beforesending the signal to the daemon because it would 
require root permissions).


_Note 3_: the daemon uses select() waiting for netlink events, and it's 
possible to add more and more file descriptors
to the poll via FD_SET(), keeping this way the daemon looking forward 
client sockets to communicate with, but i prefer to
do things the otherway around: the running process sends a signal to the 
daemon thanks the capability of the shared
library sendingafterwards therequired arguments though the server 
socket, and waiting to be listened by the client.
To finish with, at this point i must admit that i've never have had 
clear which is the server and which the client

(because i've seen everything!), but i hope you understand me :)

_Note 4_: i've done a lot of improvements in the daemon (snetaid), but i 
still didn't push them to gitea. I'll let you know.


[*] Look at the line nº 82 in the Makefile.am:

https://gitea.devuan.dev/aitor_czr/libnetaid/src/branch/master/src/Makefile.am 



[**] Now the shared library is executable:

https://gitea.devuan.dev/aitor_czr/libnetaid/src/branch/master/src/entry.c 







___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng