Chrooted mysqld sock file problem

2002-10-30 Thread Domonkos Czinke
Hi ppl :)

My question is related to a chrooted Apache(+php) and Mysql. They live
in two different chrooted environment and the problem is that I have
several php programs which wanna use the mysql, but they can't use it
since they can't find the mysql.sock file (because it in another
chroot), any idea to use apache+mysql in different chroot ? :) 

Cheers,
Domonkos Czinke


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Chrooted mysqld sock file problem

2002-10-30 Thread Emmanuel Lacour
On Wed, Oct 30, 2002 at 03:24:06PM +0100, Domonkos Czinke wrote:
 Hi ppl :)
 
 My question is related to a chrooted Apache(+php) and Mysql. They live
 in two different chrooted environment and the problem is that I have
 several php programs which wanna use the mysql, but they can't use it
 since they can't find the mysql.sock file (because it in another
 chroot), any idea to use apache+mysql in different chroot ? :) 
 

tcpip instead of unix socket ???


with something like 
bind-address = 127.0.0.1
to make it a little be less open to external if uneeded.


or maybe is it possible to share a directory where .sock are located by
bind mounting in chroots.


-- 
Easter-eggsSpécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris   -   France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76
mailto:elacour;easter-eggs.com   -http://www.easter-eggs.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Re: Chrooted mysqld sock file problem

2002-10-30 Thread weissi
Hi,
 or maybe is it possible to share a directory where .sock are located by
 bind mounting in chroots.
you yould perhaps use
/proc/mysqld-pid/root/var/run/mysqld/mysqld.sock

Regards,
weissi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: questions about chrooting bind 8.3.3

2002-10-30 Thread Sean McAvoy
Hello,
Bind has the built in ability to chroot itself (-t). then all that needs
to be done is altering the bind init script(/etc/init.d/bind), which
contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into
that variable and you should be ok. I've done this with Bind 8, and now
upgraded them to 9. 

On Tue, 2002-10-29 at 17:35, J.J. van Gorkum wrote:
 Hi, I have a question about chrooting bind 8.3.3 
 
 I have used the setup as described in
 http://people.debian.org/~pzn/howto/chroot-bind.sh.txt ... but when I
 then start bind evrything looks right but when I do a lsof -p pid of
 named I see:
 
 command to start bind:
 
 start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g
 named -t /var/lib/chroot/named/
 
 # lsof -p 22119
 COMMAND   PID  USER   FD   TYPE DEVICESIZENODE NAME
 named   22119 named  cwdDIR   8,224096  145479
 /var/lib/chroot/named/var/cache/bind
 named   22119 named  rtdDIR   8,224096  145467
 /var/lib/chroot/named
 named   22119 named  txtREG8,6  512088  130880
 /usr/sbin/named
 named   22119 named  memREG8,5   82503   30185
 /lib/ld-2.2.5.so
 named   22119 named  memREG8,5 1145456   30223
 /lib/libc-2.2.5.so
 named   22119 named  memREG8,5   32664   30232
 /lib/libnss_files-2.2.5.so
 named   22119 named0u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   22119 named1u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   22119 named2u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   22119 named3u  unix 0xe1086560 5375674 socket
 named   22119 named4u  IPv45375686 UDP *:32943 
 named   22119 named5u  unix 0xd9d1ec40 5375676 /var/run/ndc
 named   22119 named   20u  IPv45375680 UDP
 localhost:domain 
 named   22119 named   21u  IPv45375681 TCP
 localhost:domain (LISTEN)
 
 and when I change the command to start bind to :
 
 start-stop-daemon --chroot /var/lib/chroot/named/ --start --pidfile
 /var/run/named.pid --exec /usr/sbin/named -- -u named -g named
 
 I see:
 # lsof -p 23433
 COMMAND   PID  USER   FD   TYPE DEVICESIZENODE NAME
 named   23433 named  cwdDIR   8,224096  145479
 /var/lib/chroot/named/var/cache/bind
 named   23433 named  rtdDIR   8,224096  145467
 /var/lib/chroot/named
 named   23433 named  txtREG   8,22  512088  145502
 /var/lib/chroot/named/usr/sbin/named
 named   23433 named  memREG   8,22   82503  145501
 /var/lib/chroot/named/lib/ld-linux.so.2
 named   23433 named  memREG   8,22 1145456  145500
 /var/lib/chroot/named/lib/libc.so.6
 named   23433 named  memREG   8,22   32664  146115
 /var/lib/chroot/named/lib/libnss_files.so.2
 named   23433 named0u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   23433 named1u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   23433 named2u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   23433 named3u  unix 0xef055a80 5239772 socket
 named   23433 named4u  IPv45239784 UDP *:32942 
 named   23433 named5u  unix 0xeee6d140 5239774 /var/run/ndc
 named   23433 named   20u  IPv45239778 UDP
 localhost:domain 
 named   23433 named   21u  IPv45239779 TCP
 localhost:domain (LISTEN)
 
 
 Look at the difference in the libraries, as I can see when I start named
 as stated in the script the libraries in the chrooted environment are
 not used 
 
 Am I wrong here?
 -- 
 J.J. van GorkumKnowledge Zone
 --
 If UNIX isn't the solution, you've got the wrong problem.
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 
-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599



signature.asc
Description: This is a digitally signed message part


Encrypting/emailing logs and configs

2002-10-30 Thread Sean McAvoy
Hello,
I was looking at configuring a few of my VPN/Firewall systems to send me
daily backups of vital config files, and selected log files. I was
wondering what would be the easiest method of accomplishing this? I was
thinking something along the lines of just tar/bzip and then gpg to
encrypt. What other possibilities are there? And has anyone else setup
something similar?


-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599



signature.asc
Description: This is a digitally signed message part


RE: Encrypting/emailing logs and configs

2002-10-30 Thread Domonkos Czinke
How about setting up loghost server with syslog-ng ? You should send these logs via 
stunnel (secure way), sort them, compress/gpg them :) Config files problem: set up a 
Coda server (reliable and secure) on this loghost and write a script to daily copy 
your config files.

Cheers,
Domonkos Czinke

-Original Message-
From: Sean McAvoy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 30, 2002 7:08 PM
To: [EMAIL PROTECTED]
Subject: Encrypting/emailing logs and configs


Hello,
I was looking at configuring a few of my VPN/Firewall systems to send me
daily backups of vital config files, and selected log files. I was
wondering what would be the easiest method of accomplishing this? I was
thinking something along the lines of just tar/bzip and then gpg to
encrypt. What other possibilities are there? And has anyone else setup
something similar?


-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Re: Chrooted mysqld sock file problem

2002-10-30 Thread Matt Zimmerman
On Wed, Oct 30, 2002 at 03:48:32PM +0100, [EMAIL PROTECTED] wrote:

  or maybe is it possible to share a directory where .sock are located by
  bind mounting in chroots.
 you yould perhaps use
 /proc/mysqld-pid/root/var/run/mysqld/mysqld.sock

/proc/pid/root is just a symbolic link.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: questions about chrooting bind 8.3.3

2002-10-30 Thread J.J. van Gorkum
On Wed, 2002-10-30 at 18:40, Sean McAvoy wrote:
 Hello,
 Bind has the built in ability to chroot itself (-t). then all that needs
 to be done is altering the bind init script(/etc/init.d/bind), which
 contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into
 that variable and you should be ok. I've done this with Bind 8, and now
 upgraded them to 9. 

You are missing the point here, if I do it the way bind tells me in the
man pages bind is NOT using the libraries inside the chroot environment.
That is wat I try to proove with the lsmod command...



-- 
J.J. van GorkumKnowledge Zone
--
If UNIX isn't the solution, you've got the wrong problem.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Encrypting/emailing logs and configs

2002-10-30 Thread Jose Luis Domingo Lopez
On Wednesday, 30 October 2002, at 13:07:31 -0500,
Sean McAvoy wrote:

 I was looking at configuring a few of my VPN/Firewall systems to send me
 daily backups of vital config files, and selected log files. I was
 wondering what would be the easiest method of accomplishing this? I was
 thinking something along the lines of just tar/bzip and then gpg to
 encrypt. What other possibilities are there? And has anyone else setup
 something similar?
 
Maybe the followinf is too ad-hoc for your liking, but should work ok
and be reasonably easy to setup, apart from being quite secure IMO. I am
thinking about rsync over ssh, initiated from the destination backup
server to the production VPN/Firewall machine.

rsync does wonders updating trees of files in an optimal (bytes
transferred wise) way. Running over ssh, provides you with an
encrypted (and if using RSA keys authentication) authenticated
connection. Sync the times in the backup server and the firewall with
(for example) ntp o ntpdate, and create a cron job in the backup server
to initiate the backup at a certain time of the day. If both boxes are
synchronized, you could also have your iptables firewall on the
VPN/firewall box be updated to allow this backup at exactly the time of
the day you have configured.*

If the backup script, when finished, return the remote firewall ruleset
to the original state, your vulnerability window will be even shorter.

I hope to have explained myself in an understandable way ;-)

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: questions about chrooting bind 8.3.3

2002-10-30 Thread Sean McAvoy
Yes it is true that it's making use of the systems libs, but they can't
be touched by the process as it has been chrooted. In order for someone
to overwrite those files, they would first have to break of the chroot. 
I'm not sure of the real security implications of using the system libs
are vs. using chrooted libs. 


On Wed, 2002-10-30 at 15:53, J.J. van Gorkum wrote:
 On Wed, 2002-10-30 at 18:40, Sean McAvoy wrote:
  Hello,
  Bind has the built in ability to chroot itself (-t). then all that needs
  to be done is altering the bind init script(/etc/init.d/bind), which
  contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into
  that variable and you should be ok. I've done this with Bind 8, and now
  upgraded them to 9. 
 
 You are missing the point here, if I do it the way bind tells me in the
 man pages bind is NOT using the libraries inside the chroot environment.
 That is wat I try to proove with the lsmod command...
 
 
 
 -- 
 J.J. van GorkumKnowledge Zone
 --
 If UNIX isn't the solution, you've got the wrong problem.
 
-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599



signature.asc
Description: This is a digitally signed message part


Re: questions about chrooting bind 8.3.3

2002-10-30 Thread J.J. van Gorkum
On Wed, 2002-10-30 at 22:15, Sean McAvoy wrote:
 Yes it is true that it's making use of the systems libs, but they can't
 be touched by the process as it has been chrooted. In order for someone
 to overwrite those files, they would first have to break of the chroot. 
 I'm not sure of the real security implications of using the system libs
 are vs. using chrooted libs. 
 
 

Maybe I'm too much an old school admin but 'they' allways told me to
move all the libraries into the chroot environment (no symlinks
watsoever) and even (if possible) move the whole chroot environment 
onto an special (read-only) filesystem...

In my second example when I start the named daemon without the -t option
and use the (buggy) start-stop-daemon --chroot option the libraries are
used from the chroot environment. That was my point -- and it seems that
the 'standard' debian method of using a chroot environment (the link
from my original post) is moving the libraries into the chroot
environment and not using them.

-- 
J.J. van GorkumKnowledge Zone
--
If UNIX isn't the solution, you've got the wrong problem.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Encrypting/emailing logs and configs

2002-10-30 Thread Phillip Hofmeister
Greets,

On Wed, 30 Oct 2002 at 01:07:31PM -0500, Sean McAvoy wrote:
 I was looking at configuring a few of my VPN/Firewall systems to send me
 daily backups of vital config files, and selected log files. I was
 wondering what would be the easiest method of accomplishing this? I was
 thinking something along the lines of just tar/bzip and then gpg to
 encrypt. What other possibilities are there? And has anyone else setup
 something similar?
 Round about way...but set up IPSec and FTP them over the IPSec
 tunnel...or tthere is always SCP w/ keys w/o passphrases.  You trap the
 SSH in a chroot jail at the recieving end...



-- 
Phil

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import

XP Source Code:

#include win2k.h
#include extra_pretty_things_with_bugs.h
#include more_bugs.h
#include require_system_activation.h
#include phone_home_every_so_often.h
#include remote_admin_abilities_for_MS.h
#include more_restrictive_EULA.h
#include sell_your_soul_to_MS_EULA.h
//os_ver=Windows 2000
os_ver=Windows XP
--
Excuse #41: Bank holiday - system operating credits not recharged 




msg07597/pgp0.pgp
Description: PGP signature


unsubscribe

2002-10-30 Thread knoax
En réponse à Phillip Hofmeister [EMAIL PROTECTED]:

 On Mon, 28 Oct 2002 at 11:18:23PM -0800, Brandon High wrote:
  On Mon, Oct 28, 2002 at 07:38:38PM -0600, Hanasaki JiJi wrote:
   Too bad there is no way to do a secure handshake w/ an id/password
 or 
   even SecureID cards.
  
  That's the idea behind PPPoE. Yuck.
 Or you could do ipsec:
 
 Laptop (IPSEC CLient) - WAP - Server (DHCP AND IPSEC Host) - Local
 Network.  In order to get inside the network you will have to get past
 the IPSEC Host, which of course will require a key that has a valid
 certificate from the local CA.
 
 Just a thought...
 
 
 
 -- 
 Excuse #218: The co-locator cannot verify the frame-relay gateway to the
 ISDN server. 
 
 Phil
 
 PGP/GPG Key:
 http://www.zionlth.org/~plhofmei/
 wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
 
 XP Source Code:
 
 #include win2k.h
 #include extra_pretty_things_with_bugs.h
 #include more_bugs.h
 #include require_system_activation.h
 #include phone_home_every_so_often.h
 #include remote_admin_abilities_for_MS.h
 #include more_restrictive_EULA.h
 #include sell_your_soul_to_MS_EULA.h
 //os_ver=Windows 2000
 os_ver=Windows XP
 



Re: questions about chrooting bind 8.3.3

2002-10-30 Thread Lupe Christoph
Hi1

Please try not to wrap long lines in command output.

On Tuesday, 2002-10-29 at 23:35:42 +0100, J.J. van Gorkum wrote:
 Hi, I have a question about chrooting bind 8.3.3 

 I have used the setup as described in
 http://people.debian.org/~pzn/howto/chroot-bind.sh.txt ... but when I
 then start bind evrything looks right but when I do a lsof -p pid of
 named I see:

 command to start bind:

 start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g
 named -t /var/lib/chroot/named/

 # lsof -p 22119
 COMMAND   PID  USER   FD   TYPE DEVICESIZENODE NAME
 named   22119 named  cwdDIR   8,224096  145479 
 /var/lib/chroot/named/var/cache/bind
 named   22119 named  rtdDIR   8,224096  145467 
 /var/lib/chroot/named
 named   22119 named  txtREG8,6  512088  130880 /usr/sbin/named
 named   22119 named  memREG8,5   82503   30185 /lib/ld-2.2.5.so
 named   22119 named  memREG8,5 1145456   30223 /lib/libc-2.2.5.so
 named   22119 named  memREG8,5   32664   30232 
 /lib/libnss_files-2.2.5.so
 named   22119 named0u   CHR1,3  145480 
 /var/lib/chroot/named/dev/null
 named   22119 named1u   CHR1,3  145480 
 /var/lib/chroot/named/dev/null
 named   22119 named2u   CHR1,3  145480 
 /var/lib/chroot/named/dev/null
 named   22119 named3u  unix 0xe1086560 5375674 socket
 named   22119 named4u  IPv45375686 UDP *:32943 
 named   22119 named5u  unix 0xd9d1ec40 5375676 /var/run/ndc
 named   22119 named   20u  IPv45375680 UDP localhost:domain 
 named   22119 named   21u  IPv45375681 TCP localhost:domain 
 (LISTEN)

 and when I change the command to start bind to :

 start-stop-daemon --chroot /var/lib/chroot/named/ --start --pidfile
 /var/run/named.pid --exec /usr/sbin/named -- -u named -g named

 I see:
 # lsof -p 23433
 COMMAND   PID  USER   FD   TYPE DEVICESIZENODE NAME
 named   23433 named  cwdDIR   8,224096  145479 
 /var/lib/chroot/named/var/cache/bind
 named   23433 named  rtdDIR   8,224096  145467 
 /var/lib/chroot/named
 named   23433 named  txtREG   8,22  512088  145502 
 /var/lib/chroot/named/usr/sbin/named
 named   23433 named  memREG   8,22   82503  145501 
 /var/lib/chroot/named/lib/ld-linux.so.2
 named   23433 named  memREG   8,22 1145456  145500 
 /var/lib/chroot/named/lib/libc.so.6
 named   23433 named  memREG   8,22   32664  146115 
 /var/lib/chroot/named/lib/libnss_files.so.2
 named   23433 named0u   CHR1,3  145480 
 /var/lib/chroot/named/dev/null
 named   23433 named1u   CHR1,3  145480 
 /var/lib/chroot/named/dev/null
 named   23433 named2u   CHR1,3  145480 
 /var/lib/chroot/named/dev/null
 named   23433 named3u  unix 0xef055a80 5239772 socket
 named   23433 named4u  IPv45239784 UDP *:32942 
 named   23433 named5u  unix 0xeee6d140 5239774 /var/run/ndc
 named   23433 named   20u  IPv45239778 UDP localhost:domain 
 named   23433 named   21u  IPv45239779 TCP localhost:domain 
 (LISTEN)

 Look at the difference in the libraries, as I can see when I start named
 as stated in the script the libraries in the chrooted environment are
 not used 

 Am I wrong here?

Wrong in asssuming that named's dynamic libraries are linked in after
named has chorooted? Yes. Dynamic linking *must* take place before the
program gets control, or how could it use a library function otherwise?

You may need the libraries in the jail if named runs external programs.
AFAIR, named versions 4 and 8 do that, version 9 doesn't.

HTH,
Lupe Christoph
-- 
| [EMAIL PROTECTED]   |   http://www.lupe-christoph.de/ |
| Big Misunderstandings #6398: The Titanic was not supposed to be|
| unsinkable. The designer had a speech impediment. He said: I have |
| thith great unthinkable conthept ...  |



Chrooted mysqld sock file problem

2002-10-30 Thread Domonkos Czinke
Hi ppl :)

My question is related to a chrooted Apache(+php) and Mysql. They live
in two different chrooted environment and the problem is that I have
several php programs which wanna use the mysql, but they can't use it
since they can't find the mysql.sock file (because it in another
chroot), any idea to use apache+mysql in different chroot ? :) 

Cheers,
Domonkos Czinke



Re: Chrooted mysqld sock file problem

2002-10-30 Thread Emmanuel Lacour
On Wed, Oct 30, 2002 at 03:24:06PM +0100, Domonkos Czinke wrote:
 Hi ppl :)
 
 My question is related to a chrooted Apache(+php) and Mysql. They live
 in two different chrooted environment and the problem is that I have
 several php programs which wanna use the mysql, but they can't use it
 since they can't find the mysql.sock file (because it in another
 chroot), any idea to use apache+mysql in different chroot ? :) 
 

tcpip instead of unix socket ???


with something like 
bind-address = 127.0.0.1
to make it a little be less open to external if uneeded.


or maybe is it possible to share a directory where .sock are located by
bind mounting in chroots.


-- 
Easter-eggsSpécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris   -   France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76
mailto:[EMAIL PROTECTED]   -http://www.easter-eggs.com



Re: Chrooted mysqld sock file problem

2002-10-30 Thread Cesare Fontana

Domonkos Czinke wrote:

Hi ppl :)

My question is related to a chrooted Apache(+php) and Mysql. They live
in two different chrooted environment and the problem is that I have
several php programs which wanna use the mysql, but they can't use it
since they can't find the mysql.sock file (because it in another
chroot), any idea to use apache+mysql in different chroot ? :) 


Cheers,
Domonkos Czinke


try to use  network (comment skip_networking in my.conf) connection and 
filter it

with an  ipchains/iptables rule..




Re: Re: Chrooted mysqld sock file problem

2002-10-30 Thread weissi
Hi,
 or maybe is it possible to share a directory where .sock are located by
 bind mounting in chroots.
you yould perhaps use
/proc/mysqld-pid/root/var/run/mysqld/mysqld.sock

Regards,
weissi



Re: questions about chrooting bind 8.3.3

2002-10-30 Thread Sean McAvoy
Hello,
Bind has the built in ability to chroot itself (-t). then all that needs
to be done is altering the bind init script(/etc/init.d/bind), which
contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into
that variable and you should be ok. I've done this with Bind 8, and now
upgraded them to 9. 

On Tue, 2002-10-29 at 17:35, J.J. van Gorkum wrote:
 Hi, I have a question about chrooting bind 8.3.3 
 
 I have used the setup as described in
 http://people.debian.org/~pzn/howto/chroot-bind.sh.txt ... but when I
 then start bind evrything looks right but when I do a lsof -p pid of
 named I see:
 
 command to start bind:
 
 start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g
 named -t /var/lib/chroot/named/
 
 # lsof -p 22119
 COMMAND   PID  USER   FD   TYPE DEVICESIZENODE NAME
 named   22119 named  cwdDIR   8,224096  145479
 /var/lib/chroot/named/var/cache/bind
 named   22119 named  rtdDIR   8,224096  145467
 /var/lib/chroot/named
 named   22119 named  txtREG8,6  512088  130880
 /usr/sbin/named
 named   22119 named  memREG8,5   82503   30185
 /lib/ld-2.2.5.so
 named   22119 named  memREG8,5 1145456   30223
 /lib/libc-2.2.5.so
 named   22119 named  memREG8,5   32664   30232
 /lib/libnss_files-2.2.5.so
 named   22119 named0u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   22119 named1u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   22119 named2u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   22119 named3u  unix 0xe1086560 5375674 socket
 named   22119 named4u  IPv45375686 UDP *:32943 
 named   22119 named5u  unix 0xd9d1ec40 5375676 /var/run/ndc
 named   22119 named   20u  IPv45375680 UDP
 localhost:domain 
 named   22119 named   21u  IPv45375681 TCP
 localhost:domain (LISTEN)
 
 and when I change the command to start bind to :
 
 start-stop-daemon --chroot /var/lib/chroot/named/ --start --pidfile
 /var/run/named.pid --exec /usr/sbin/named -- -u named -g named
 
 I see:
 # lsof -p 23433
 COMMAND   PID  USER   FD   TYPE DEVICESIZENODE NAME
 named   23433 named  cwdDIR   8,224096  145479
 /var/lib/chroot/named/var/cache/bind
 named   23433 named  rtdDIR   8,224096  145467
 /var/lib/chroot/named
 named   23433 named  txtREG   8,22  512088  145502
 /var/lib/chroot/named/usr/sbin/named
 named   23433 named  memREG   8,22   82503  145501
 /var/lib/chroot/named/lib/ld-linux.so.2
 named   23433 named  memREG   8,22 1145456  145500
 /var/lib/chroot/named/lib/libc.so.6
 named   23433 named  memREG   8,22   32664  146115
 /var/lib/chroot/named/lib/libnss_files.so.2
 named   23433 named0u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   23433 named1u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   23433 named2u   CHR1,3  145480
 /var/lib/chroot/named/dev/null
 named   23433 named3u  unix 0xef055a80 5239772 socket
 named   23433 named4u  IPv45239784 UDP *:32942 
 named   23433 named5u  unix 0xeee6d140 5239774 /var/run/ndc
 named   23433 named   20u  IPv45239778 UDP
 localhost:domain 
 named   23433 named   21u  IPv45239779 TCP
 localhost:domain (LISTEN)
 
 
 Look at the difference in the libraries, as I can see when I start named
 as stated in the script the libraries in the chrooted environment are
 not used 
 
 Am I wrong here?
 -- 
 J.J. van GorkumKnowledge Zone
 --
 If UNIX isn't the solution, you've got the wrong problem.
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 
-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599


signature.asc
Description: This is a digitally signed message part


Encrypting/emailing logs and configs

2002-10-30 Thread Sean McAvoy
Hello,
I was looking at configuring a few of my VPN/Firewall systems to send me
daily backups of vital config files, and selected log files. I was
wondering what would be the easiest method of accomplishing this? I was
thinking something along the lines of just tar/bzip and then gpg to
encrypt. What other possibilities are there? And has anyone else setup
something similar?


-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599


signature.asc
Description: This is a digitally signed message part


RE: Encrypting/emailing logs and configs

2002-10-30 Thread Domonkos Czinke
How about setting up loghost server with syslog-ng ? You should send these logs 
via stunnel (secure way), sort them, compress/gpg them :) Config files problem: 
set up a Coda server (reliable and secure) on this loghost and write a script 
to daily copy your config files.

Cheers,
Domonkos Czinke

-Original Message-
From: Sean McAvoy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 30, 2002 7:08 PM
To: debian-security@lists.debian.org
Subject: Encrypting/emailing logs and configs


Hello,
I was looking at configuring a few of my VPN/Firewall systems to send me
daily backups of vital config files, and selected log files. I was
wondering what would be the easiest method of accomplishing this? I was
thinking something along the lines of just tar/bzip and then gpg to
encrypt. What other possibilities are there? And has anyone else setup
something similar?


-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599



Re: Re: Chrooted mysqld sock file problem

2002-10-30 Thread Matt Zimmerman
On Wed, Oct 30, 2002 at 03:48:32PM +0100, [EMAIL PROTECTED] wrote:

  or maybe is it possible to share a directory where .sock are located by
  bind mounting in chroots.
 you yould perhaps use
 /proc/mysqld-pid/root/var/run/mysqld/mysqld.sock

/proc/pid/root is just a symbolic link.

-- 
 - mdz



Re: questions about chrooting bind 8.3.3

2002-10-30 Thread J.J. van Gorkum
On Wed, 2002-10-30 at 18:40, Sean McAvoy wrote:
 Hello,
 Bind has the built in ability to chroot itself (-t). then all that needs
 to be done is altering the bind init script(/etc/init.d/bind), which
 contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into
 that variable and you should be ok. I've done this with Bind 8, and now
 upgraded them to 9. 

You are missing the point here, if I do it the way bind tells me in the
man pages bind is NOT using the libraries inside the chroot environment.
That is wat I try to proove with the lsmod command...



-- 
J.J. van GorkumKnowledge Zone
--
If UNIX isn't the solution, you've got the wrong problem.



Re: Encrypting/emailing logs and configs

2002-10-30 Thread Jose Luis Domingo Lopez
On Wednesday, 30 October 2002, at 13:07:31 -0500,
Sean McAvoy wrote:

 I was looking at configuring a few of my VPN/Firewall systems to send me
 daily backups of vital config files, and selected log files. I was
 wondering what would be the easiest method of accomplishing this? I was
 thinking something along the lines of just tar/bzip and then gpg to
 encrypt. What other possibilities are there? And has anyone else setup
 something similar?
 
Maybe the followinf is too ad-hoc for your liking, but should work ok
and be reasonably easy to setup, apart from being quite secure IMO. I am
thinking about rsync over ssh, initiated from the destination backup
server to the production VPN/Firewall machine.

rsync does wonders updating trees of files in an optimal (bytes
transferred wise) way. Running over ssh, provides you with an
encrypted (and if using RSA keys authentication) authenticated
connection. Sync the times in the backup server and the firewall with
(for example) ntp o ntpdate, and create a cron job in the backup server
to initiate the backup at a certain time of the day. If both boxes are
synchronized, you could also have your iptables firewall on the
VPN/firewall box be updated to allow this backup at exactly the time of
the day you have configured.*

If the backup script, when finished, return the remote firewall ruleset
to the original state, your vulnerability window will be even shorter.

I hope to have explained myself in an understandable way ;-)

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Woody (Linux 2.4.19-pre6aa1)



Re: questions about chrooting bind 8.3.3

2002-10-30 Thread Sean McAvoy
Yes it is true that it's making use of the systems libs, but they can't
be touched by the process as it has been chrooted. In order for someone
to overwrite those files, they would first have to break of the chroot. 
I'm not sure of the real security implications of using the system libs
are vs. using chrooted libs. 


On Wed, 2002-10-30 at 15:53, J.J. van Gorkum wrote:
 On Wed, 2002-10-30 at 18:40, Sean McAvoy wrote:
  Hello,
  Bind has the built in ability to chroot itself (-t). then all that needs
  to be done is altering the bind init script(/etc/init.d/bind), which
  contains the OPTS variable. Add '-u [username] -t [chroot_dir]' into
  that variable and you should be ok. I've done this with Bind 8, and now
  upgraded them to 9. 
 
 You are missing the point here, if I do it the way bind tells me in the
 man pages bind is NOT using the libraries inside the chroot environment.
 That is wat I try to proove with the lsmod command...
 
 
 
 -- 
 J.J. van GorkumKnowledge Zone
 --
 If UNIX isn't the solution, you've got the wrong problem.
 
-- 
Sean McAvoy
Network Analyst
Megawheels Technologies Inc.
Phone: 416.360.8211
Fax:   416.360.1403
Cell:  416.616.6599


signature.asc
Description: This is a digitally signed message part


Re: questions about chrooting bind 8.3.3

2002-10-30 Thread J.J. van Gorkum
On Wed, 2002-10-30 at 22:15, Sean McAvoy wrote:
 Yes it is true that it's making use of the systems libs, but they can't
 be touched by the process as it has been chrooted. In order for someone
 to overwrite those files, they would first have to break of the chroot. 
 I'm not sure of the real security implications of using the system libs
 are vs. using chrooted libs. 
 
 

Maybe I'm too much an old school admin but 'they' allways told me to
move all the libraries into the chroot environment (no symlinks
watsoever) and even (if possible) move the whole chroot environment 
onto an special (read-only) filesystem...

In my second example when I start the named daemon without the -t option
and use the (buggy) start-stop-daemon --chroot option the libraries are
used from the chroot environment. That was my point -- and it seems that
the 'standard' debian method of using a chroot environment (the link
from my original post) is moving the libraries into the chroot
environment and not using them.

-- 
J.J. van GorkumKnowledge Zone
--
If UNIX isn't the solution, you've got the wrong problem.