Re: [DNG] Mirroring Devuan
Hi all,
Take the case two mirrors, a complete Debian mirror in DEBIAN folder,
and the merged packages in DEVUAN folder, containing both their
corresponding /dists/ and /pool/. The following scripts build the /dist/
and /pool/ from the content of them, giving priority to Devuan. The
script1 calls to the script2:
** SCRIPT1:
#!/bin/sh
find ./DEBIAN -name "*.dsc" -exec ./script2 {} \;
exit 0
** END OF THE SCRIPT1
** SCRIPT2:
#!/bin/sh
line1=${1%/*}
line2=${line1#*/}
line3=${line2#*/}
### The above lines converts
###./DEBIAN/pool/main/main/l/linux/linux_3.16.7-ckt11-1+deb8u3.dsc
### in /pool/main/main/l/linux
### The relationship betwen paths and sources is biyective
if [ -d ./DEVUAN/$line3 ];
then
find ./DEVUAN -name "*.deb" -exec reprepro --ask-passphrase -b . -V -C
main includedeb jessie {} \;
find ./DEVUAN -name "*.udeb" -exec reprepro --ask-passphrase -b . -V
-C main includeudeb jessie {} \;
find ./DEVUAN -name "*.dsc" -exec reprepro --ask-passphrase -b . -V -C
main includedsc jessie {} \;
exit 0
fi
find ./DEBIAN -name "*.deb" -exec reprepro --ask-passphrase -b . -V -C
main includedeb jessie {} \;
find ./DEBIAN -name "*.udeb" -exec reprepro --ask-passphrase -b . -V -C
main includeudeb jessie {} \;
find ./DEBIAN -name "*.dsc" -exec reprepro --ask-passphrase -b . -V -C
main includedsc jessie {} \;
exit 0
** END OF THE SCRIPT2
For each description file *.dsc found in the frist script, the second
script searches in the corresponding path in ./DEVUAN. If it exits,
DEBIAN packages are ignored.
There are some stuffs to add: debian must be changed by devuan in the
path (debian-keyring by devuan-keyring, etc), a black list for debian,
extra packages nonexistent in debian...
Aitor
Jaromil:
we haven't yet worked on the mirroring mechanism, but we will
once done, there will be a script and it will be easy
I guess it will be a sort of amprolla satellite process
so that the mirror redirection will be handled by nextime's software
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirroring Devuan
In the second script, i forgot adding $line3 in the path to 'find', so i
rectify:
** SCRIPT1:
#!/bin/sh
find ./DEBIAN -name "*.dsc" -exec ./script2 {} \;
exit 0
** END OF THE SCRIPT1
** SCRIPT2:
#!/bin/sh
line1=${1%/*}
line2=${line1#*/}
line3=${line2#*/}
if [ -d ./DEVUAN/$line3 ];
then
find ./DEVUAN/$line3 -name "*.deb" -exec reprepro --ask-passphrase
-b . -V -C main includedeb jessie {} \;
find ./DEVUAN/$line3 -name "*.udeb" -exec reprepro --ask-passphrase
-b . -V -C main includeudeb jessie {} \;
find ./DEVUAN/$line3 -name "*.dsc" -exec reprepro --ask-passphrase
-b . -V -C main includedsc jessie {} \;
exit 0
fi
find ./DEBIAN/$line3 -name "*.deb" -exec reprepro --ask-passphrase -b .
-V -C main includedeb jessie {} \;
find ./DEBIAN/$line3 -name "*.udeb" -exec reprepro --ask-passphrase -b .
-V -C main includeudeb jessie {} \;
find ./DEBIAN/$line3 -name "*.dsc" -exec reprepro --ask-passphrase -b .
-V -C main includedsc jessie {} \;
exit 0
** END OF THE SCRIPT2
Aitor.
On 08/09/15 09:31, aitor_czr wrote:
Hi all,
Take the case two mirrors, a complete Debian mirror in DEBIAN folder,
and the merged packages in DEVUAN folder, containing both their
corresponding/dists/ and/pool/. The following scripts build the/dist/
and/pool/ from the content of them, giving priority to Devuan. The
script1 calls to the script2:
** SCRIPT1:
#!/bin/sh
find ./DEBIAN -name "*.dsc" -exec ./script2 {} \;
exit 0
** END OF THE SCRIPT1
** SCRIPT2:
#!/bin/sh
line1=${1%/*}
line2=${line1#*/}
line3=${line2#*/}
### The above lines converts
###./DEBIAN/pool/main/main/l/linux/linux_3.16.7-ckt11-1+deb8u3.dsc
### in /pool/main/main/l/linux
### The relationship betwen paths and sources is biyective
if [ -d ./DEVUAN/$line3 ];
then
find ./DEVUAN -name "*.deb" -exec reprepro --ask-passphrase -b . -V -C
main includedeb jessie {} \;
find ./DEVUAN -name "*.udeb" -exec reprepro --ask-passphrase -b . -V
-C main includeudeb jessie {} \;
find ./DEVUAN -name "*.dsc" -exec reprepro --ask-passphrase -b . -V -C
main includedsc jessie {} \;
exit 0
fi
find ./DEBIAN -name "*.deb" -exec reprepro --ask-passphrase -b . -V -C
main includedeb jessie {} \;
find ./DEBIAN -name "*.udeb" -exec reprepro --ask-passphrase -b . -V -C
main includeudeb jessie {} \;
find ./DEBIAN -name "*.dsc" -exec reprepro --ask-passphrase -b . -V -C
main includedsc jessie {} \;
exit 0
** END OF THE SCRIPT2
For each description file *.dsc found in the frist script, the second
script searches in the corresponding path in ./DEVUAN. If it exits,
DEBIAN packages are ignored.
There are some stuffs to add: debian must be changed by devuan in the
path (debian-keyring by devuan-keyring, etc), a black list for debian,
extra packages nonexistent in debian...
Aitor
Jaromil:
>>we haven't yet worked on the mirroring mechanism, but we will
>>
>>once done, there will be a script and it will be easy
>>I guess it will be a sort of amprolla satellite process
>>so that the mirror redirection will be handled by nextime's software
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Ktorrent missing
Hi, since from yesterday, there is no ktorrent in repository. -- Alessandro Sangiorgi ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Actually, you can do away with using a root SUID for backend as that was initially how netman was designed. However, there were complaints that I was adding an extra dependency which simply was a dependency on sudo being installed. Moreover, my initial proposal that worked, used sudo in a way to only allow the backend to run; so, it was NOT configured the way sudo is on Ubuntu. Regarding the backend calling external processes, this is done through execl and popen. Calls to external processes were modified as soon as I uploaded my unfinished code the first time. There were justified claims like yours, that there were security issues with my code. I heeded those advices by actually letting other developers modify the code so that, security would not be compromised. Edward On 08/09/2015, Tobias Hunger wrote: > Am 08.09.2015 08:40 schrieb "Edward Bartolo" : >> And: >> backend's SUID will be changed to that belonging to root. (as root: >> chmod u+s backend) > > Suid root is a huge security risk, especially when handling user input and > when calling out to external processes. Your back end does both:-/ > > So I am wondering: Is the network capability enough or do you really need > the binary to be suid root? > > Best Regards, > Tobias > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Quote: << Maybe you could get away with setting only one capability on the back end instead of handing it full root privileges. Maybe there is a group that has special privileges to run the necessary binaries? Then you could sgid your back end to that group id, severely limiting the damage any exploit that may or may not exist in your code can do to the system.>> This seems to be a good suggestion if I understood you well. So, you are suggesting to create a user group that would be given rights to run the processes the backend calls? This sounds a lesser security risk than using a full blown root SUID for backend. Another way, is to make the backend self contained and do away completely with using external process to connect and disconnect, but that requires quite a good deal of coding time. Thanks for your contribution. Edward On 08/09/2015, Tobias Hunger wrote: > Am 08.09.2015 20:30 schrieb "Edward Bartolo" : >> >> Actually, you can do away with using a root SUID for backend as that >> was initially how netman was designed. However, there were complaints >> that I was adding an extra dependency which simply was a dependency on >> sudo being installed. Moreover, my initial proposal that worked, used >> sudo in a way to only allow the backend to run; so, it was NOT >> configured the way sudo is on Ubuntu. > > Suid or sudo does not make a big difference: In the end you run the back > end with full root privileges. > > Capabilities were introduced to be able to have "miniroot" users that can > change on aspect of the system (e.g. manage the network) but not the > others. A significant amount of former SUID binaries were adapted to rely > on capabilities instead. > > Note: With most capabilities you can actually acquire more since they are > still too powerful, but that is one extra step an attacker has to make. > >> Regarding the backend calling external processes, this is done through >> execl and popen. Calls to external processes were modified as soon as >> I uploaded my unfinished code the first time. There were justified >> claims like yours, that there were security issues with my code. I >> heeded those advices by actually letting other developers modify the >> code so that, security would not be compromised. > > I have not looked at your code, so I can not comment on whether or not (I > think) it is secure or not. But all it takes to have an exploit is to make > one little mistake... everybody makes mistakes, so it is a established > security best practice to hand out only those privileges necessary to > accomplish any task. > > Maybe you could get away with setting only one capability on the back end > instead of handing it full root privileges. Maybe there is a group that has > special privileges to run the necessary binaries? Then you could sgid your > back end to that group id, severely limiting the damage any exploit that > may or may not exist in your code can do to the system. > > Best Regards, > Tobias > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Hi all, I think, a simple way to avoid the backend having to call external programs like ifup and ifdown, is to use code belonging to these programs as it they were functions. This means, their code would be used like this: Suppose int main(int argc, char * argv[]) is the main function for ifup. The main function's name would be changed like this, and the other code belonging to ifup would be used. int ifup_main(int argc, char * argv[]); If I am correct, this should allow the backend to avoid having to use execl to call ifup or ifdown or whatever other external program. Edward On 08/09/2015, Edward Bartolo wrote: > Quote: << Maybe you could get away with setting only one capability on > the back end instead of handing it full root privileges. Maybe there > is a group that has special privileges to run the necessary binaries? > Then you could sgid your back end to that group id, severely limiting > the damage any exploit that may or may not exist in your code can do > to the system.>> > > This seems to be a good suggestion if I understood you well. > > So, you are suggesting to create a user group that would be given > rights to run the processes the backend calls? This sounds a lesser > security risk than using a full blown root SUID for backend. > > Another way, is to make the backend self contained and do away > completely with using external process to connect and disconnect, but > that requires quite a good deal of coding time. > > Thanks for your contribution. > > Edward > > On 08/09/2015, Tobias Hunger wrote: >> Am 08.09.2015 20:30 schrieb "Edward Bartolo" : >>> >>> Actually, you can do away with using a root SUID for backend as that >>> was initially how netman was designed. However, there were complaints >>> that I was adding an extra dependency which simply was a dependency on >>> sudo being installed. Moreover, my initial proposal that worked, used >>> sudo in a way to only allow the backend to run; so, it was NOT >>> configured the way sudo is on Ubuntu. >> >> Suid or sudo does not make a big difference: In the end you run the back >> end with full root privileges. >> >> Capabilities were introduced to be able to have "miniroot" users that can >> change on aspect of the system (e.g. manage the network) but not the >> others. A significant amount of former SUID binaries were adapted to rely >> on capabilities instead. >> >> Note: With most capabilities you can actually acquire more since they are >> still too powerful, but that is one extra step an attacker has to make. >> >>> Regarding the backend calling external processes, this is done through >>> execl and popen. Calls to external processes were modified as soon as >>> I uploaded my unfinished code the first time. There were justified >>> claims like yours, that there were security issues with my code. I >>> heeded those advices by actually letting other developers modify the >>> code so that, security would not be compromised. >> >> I have not looked at your code, so I can not comment on whether or not (I >> think) it is secure or not. But all it takes to have an exploit is to >> make >> one little mistake... everybody makes mistakes, so it is a established >> security best practice to hand out only those privileges necessary to >> accomplish any task. >> >> Maybe you could get away with setting only one capability on the back end >> instead of handing it full root privileges. Maybe there is a group that >> has >> special privileges to run the necessary binaries? Then you could sgid >> your >> back end to that group id, severely limiting the damage any exploit that >> may or may not exist in your code can do to the system. >> >> Best Regards, >> Tobias >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Edward Bartolo writes: > Actually, you can do away with using a root SUID for backend as that > was initially how netman was designed. However, there were complaints > that I was adding an extra dependency which simply was a dependency on > sudo being installed. Moreover, my initial proposal that worked, used > sudo in a way to only allow the backend to run; so, it was NOT > configured the way sudo is on Ubuntu. > > Regarding the backend calling external processes, this is done through > execl and popen. Calls to external processes were modified as soon as > I uploaded my unfinished code the first time. There were justified > claims like yours, that there were security issues with my code. I > heeded those advices by actually letting other developers modify the > code so that, security would not be compromised. The short reply to the e-mail you were replying to is: "This is bollocks as there's no real 'security boundary' here, it's about a single user configuring his own system". The only data from possibly untrusted sources you're dealing with are the SSIDs. Someone who is concerned about this can try to configure this with the 'file system capabilities' he'd like to have it instead and change whatever needs to be changed to make it work "like Fedora". But this is essentially just hand-waiving in order to scare 'the unknown software error' and 'the unkown software error' may well lurk in the capability-handling code itself. Better go and find some real bugs and fix them. NB: I don't claim that there are no security-related bugs in this code as I haven't checked it for them (and might be wrong if I had), however, pointing out that there 'might' be such bugs is a waste of oxygen (IMHO). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Hi Edward, Don't change the name of the main funtion. In order to distinguish between ifup and ifdown, you can use one of the arguments, for example argv[1] (the first one *int argc* is the number of arguments in the command line (+1) included itself) . Aitor. El 08/09/15 a las 21:40, Edward Bartolo escribió: Hi all, I think, a simple way to avoid the backend having to call external programs like ifup and ifdown, is to use code belonging to these programs as it they were functions. This means, their code would be used like this: Suppose int main(int argc, char * argv[]) is the main function for ifup. The main function's name would be changed like this, and the other code belonging to ifup would be used. int ifup_main(int argc, char * argv[]); If I am correct, this should allow the backend to avoid having to use execl to call ifup or ifdown or whatever other external program. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, Sep 08, 2015 at 09:40:12PM +0200, Edward Bartolo wrote: > Hi all, > > I think, a simple way to avoid the backend having to call external > programs like ifup and ifdown, is to use code belonging to these > programs as it they were functions. This means, their code would be > used like this: > > Suppose int main(int argc, char * argv[]) is the main function for > ifup. The main function's name would be changed like this, and the > other code belonging to ifup would be used. > > int ifup_main(int argc, char * argv[]); > > If I am correct, this should allow the backend to avoid having to use > execl to call ifup or ifdown or whatever other external program. > So you are basically suggesting that your backend should swallow ifup, ifdown and who knows how many other executables, just because you don't want to call execl? No matter where the code of ifup lives, it requires root privileges to do anything relevant, so having it inside your backend won't avoid having at least one executable with SUID set (the backend), or launched by init as a daemon (and thus owned by root). I still don't see why on Earth you want to "avoid having to use execl to call ifup". Esecuting an existing command-line program into a child is exactly what the wide majority of all the ncurses and GUIs frontends (not just for network config) actually do. This is the normal way of doing things. "Incorporating code from other programs" == "bloating your little software". My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, Sep 08, 2015 at 11:53:33PM +0100, KatolaZ wrote: > On Tue, Sep 08, 2015 at 09:40:12PM +0200, Edward Bartolo wrote: > > Hi all, > > > > I think, a simple way to avoid the backend having to call external > > programs like ifup and ifdown, is to use code belonging to these > > programs as it they were functions. This means, their code would be > > used like this: > > > > Suppose int main(int argc, char * argv[]) is the main function for > > ifup. The main function's name would be changed like this, and the > > other code belonging to ifup would be used. > > > > int ifup_main(int argc, char * argv[]); > > > > If I am correct, this should allow the backend to avoid having to use > > execl to call ifup or ifdown or whatever other external program. > > > > So you are basically suggesting that your backend should swallow ifup, > ifdown and who knows how many other executables, just because you > don't want to call execl? No matter where the code of ifup lives, it > requires root privileges to do anything relevant, so having it inside > your backend won't avoid having at least one executable with SUID set > (the backend), or launched by init as a daemon (and thus owned by > root). > > I still don't see why on Earth you want to "avoid having to use execl > to call ifup". Esecuting an existing command-line program into a child > is exactly what the wide majority of all the ncurses and GUIs > frontends (not just for network config) actually do. This is the > normal way of doing things. > > "Incorporating code from other programs" == "bloating your little > software". Which has implications for maintainability. Your code won't benefit from bug fixes made to ifup. Except, of course, the ifup code is a thin command-language wrapper around a shared library or system call that does the actual work; then just calling the shared library or system call is OK. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Hi all, Having read your replies, I think, the best option is NOT to change netman's backend as suggested by Tobias Hunger. This means, I will heed the advice of Rainer Weikusat, KatolaZ and Hendrik Boom. Regarding the advice from aitor_czr, I wish to thank aitor, notwithstanding I will not need to change anything. As it is, netman is functioning happily, even giving the choice of closing it while the connection remains strong, dependable and lasting. This is a plus compared to other network managers. Your support is greatly appreciated. Edward On 09/09/2015, Edward Bartolo wrote: > Hi all, > > Having read your replies, I think, the best option is NOT to change > netman's backend as suggested by Tobias Hunger. This means, I will > heed the advice of Rainer Weikusat, KatolaZ and Hendrik Boom. > > Regarding the advice from aitor_czr, I wish to thank aitor, > notwithstanding I will not need to change anything. > > As it is, netman is functioning happily, even giving the choice of > closing it while the connection remains strong, dependable and > lasting. This is a plus compared to other network managers. > > Your support is greatly appreciated. > > Edward > > On 09/09/2015, Hendrik Boom wrote: >> On Tue, Sep 08, 2015 at 11:53:33PM +0100, KatolaZ wrote: >>> On Tue, Sep 08, 2015 at 09:40:12PM +0200, Edward Bartolo wrote: >>> > Hi all, >>> > >>> > I think, a simple way to avoid the backend having to call external >>> > programs like ifup and ifdown, is to use code belonging to these >>> > programs as it they were functions. This means, their code would be >>> > used like this: >>> > >>> > Suppose int main(int argc, char * argv[]) is the main function for >>> > ifup. The main function's name would be changed like this, and the >>> > other code belonging to ifup would be used. >>> > >>> > int ifup_main(int argc, char * argv[]); >>> > >>> > If I am correct, this should allow the backend to avoid having to use >>> > execl to call ifup or ifdown or whatever other external program. >>> > >>> >>> So you are basically suggesting that your backend should swallow ifup, >>> ifdown and who knows how many other executables, just because you >>> don't want to call execl? No matter where the code of ifup lives, it >>> requires root privileges to do anything relevant, so having it inside >>> your backend won't avoid having at least one executable with SUID set >>> (the backend), or launched by init as a daemon (and thus owned by >>> root). >>> >>> I still don't see why on Earth you want to "avoid having to use execl >>> to call ifup". Esecuting an existing command-line program into a child >>> is exactly what the wide majority of all the ncurses and GUIs >>> frontends (not just for network config) actually do. This is the >>> normal way of doing things. >>> >>> "Incorporating code from other programs" == "bloating your little >>> software". >> >> Which has implications for maintainability. Your code won't benefit >> from bug fixes made to ifup. >> >> Except, of course, the ifup code is a thin command-language wrapper >> around a shared library or system call that does the actual work; then >> just calling the shared library or system call is OK. >> >> >> -- hendrik >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
