Re: [CentOS] trouble installing Math::BigInt module

[Bennett Haselton]

On 3/31/2014 10:42 PM, Tom Robinson wrote:
 On 01/04/14 16:19, Bennett Haselton wrote:
 On 3/31/2014 7:56 PM, Tom Robinson wrote:
 Can you verify to which packages thefiles belong?

 Try using RPM:

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm
 On the old machine:
 perl-Net-IP-1.25-2.fc6
 and

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm
 On the new machine:
 perl-Crypt-DSA-1.16-1.el5.rf
 That should be a good starting point. Your check on installed packages as 
 preposed by John shows two
 very different packaged environments. Did you ever use CPAN on the old or new 
 machine?
Yes, on both.  I needed it because I needed to install Crypt::Twofish 
and it didn't seem to be available from the default repositories used by 
yum but it was available from CPAN.

Because there were dozens of sources that I read, plus probably 
thousands of others that I didn't read, saying that installing from CPAN 
was a way to install Perl modules, I figured it was reasonably safe to 
follow those directions, so I went ahead and did it.

Now, later I found out that you can get your machine into an 
inconsistent state by installing things from both CPAN and yum 
repositories, and moreover apparently you can't even properly uninstall 
things that are installed by CPAN:
http://stackoverflow.com/questions/2626449/how-can-i-de-install-a-perl-module-installed-via-cpan
so by following directions to the letter which are repeated in thousands 
of sources, I apparently put my machine in a state that will cause 
frequent unpredictable conflicts with all the things installed by the 
system package manager, and the damage is irreversible.

Is that about right? :)

At about the same time I learned not to use CPAN, the person helping me 
solve the current problem said that I could make the run-time errors go 
away by going into CPAN and install Math::BigInt -- which led to a new 
error, getting Math::BigInt: couldn't load specified math lib(s), 
fallback to Math::BigInt::Calc at 
/usr/lib/perl5/vendor_perl/5.8.8/Crypt/DH.pm line 6, so then I 
installed Math::BigInt::Pari through CPAN and it fixed the problem. I 
had to use CPAN because it was the only solution he knew and it was an 
emergency to get that error fixed.

So, going forward, to mitigate the damage, should I just take all the 
packages that are currently only listed as installed on the old machine, 
truncate the version number (so e.g. truncate 
perl-Compress-Raw-Zlib-2.052-1.el5.rf to just 
perl-Compress-Raw-Zlib2) and install that with yum on the command 
line?  (Thanks for that list, by the way.)

And more generally, what is the best practice if I want to install a 
module like Crypt::Twofish that was not in the default yum repositories, 
if John and C.L. are saying to avoid CPAN, and both John and Tom are 
saying to avoid adding extra yum repositories?  I'd like to use yum just 
for consistency since it automatically handles dependencies and such, 
and at least if I always use yum, then yum will always be aware of 
what's installed already (as opposed to things installed from CPAN).

Bennett

 I would work
 to bring the new machine's perl environment as close to that of the old 
 machine's.

 Indeed, perl-Net-SFTP package is only installed on the new machine!

 Your package output is reformatted here. Work through this to bring your 
 environments as close as
 possible and check if you have used CPAN to install packages in the past.

 $ diff -yW80 /tmp/oldlist /tmp/newlist
 perl-5.8.8-41.el5   perl-5.8.8-41.el5
 perl-Compress-Raw-Bzip2-2.052-1.el5.r | perl-Class-Loader-2.03-1.2.el5.rf
 perl-Compress-Raw-Zlib-2.052-1.el5.rf | perl-Compress-Zlib-1.42-1.fc6
 perl-Convert-ASN1-0.22-1.el5.rf   | perl-Convert-ASCII-Armour-1.4-1.2.el5
 perl-Crypt-SSLeay-0.57-3.el5.rf   | perl-Convert-ASN1-0.20-1.1
 perl-DBD-mysql-4.014-1.el5.rf | perl-Convert-PEM-0.07-1.2.el5.rf
 perl-DBI-1.615-1.el5.rf   | perl-Crypt-CBC-2.30-1.el5.rf
 perl-Crypt-DES-2.05-3.2.el5.rf
 perl-Crypt-DH-0.06-1.2.el5.rf
 perl-Crypt-DSA-1.16-1.el5.rf
 perl-Crypt-IDEA-1.08-1.el5.rf
 perl-Crypt-Primes-0.50-1.2.el5.rf
 perl-Crypt-RSA-1.99-1.el5.rf
 perl-Crypt-Random-1.25-1.2.el5.rf
 perl-Crypt-Twofish-2.13-1.el5.rf
 perl-DBD-MySQL-3.0007-2.el5
 perl-DBI-1.52-2.el5
 perl-Data-Buffer-0.04-1.2.el5.rf
 perl-Digest-HMAC-1.01-15perl-Digest-HMAC-1.01-15
 perl-Digest-MD2-2.03-1.2.el5.rf
 perl-Digest-SHA1-2.11-1.2.1 perl-Digest-SHA1-2.11-1.2.1
 perl-Email-Date

Re: [CentOS] trouble installing Math::BigInt module

[Bennett Haselton]

On 4/1/2014 4:10 PM, Tom Robinson wrote:
 Tom Robinson
 IT Manager/System Administrator

 MoTeC Pty Ltd

 121 Merrindale Drive
 Croydon South
 3136 Victoria
 Australia

 T: +61 3 9761 5050
 F: +61 3 9761 5051
 E: tom.robin...@motec.com.au

 On 01/04/14 19:04, Bennett Haselton wrote:
 On 3/31/2014 10:42 PM, Tom Robinson wrote:
 On 01/04/14 16:19, Bennett Haselton wrote:
 On 3/31/2014 7:56 PM, Tom Robinson wrote:
 Can you verify to which packages thefiles belong?

 Try using RPM:

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm
 On the old machine:
 perl-Net-IP-1.25-2.fc6
 and

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm
 On the new machine:
 perl-Crypt-DSA-1.16-1.el5.rf
 That should be a good starting point. Your check on installed packages as 
 preposed by John shows two
 very different packaged environments. Did you ever use CPAN on the old or 
 new machine?
 Yes, on both.  I needed it because I needed to install Crypt::Twofish
 and it didn't seem to be available from the default repositories used by
 yum but it was available from CPAN.
 So I stand alone on this, but CPAN can work. I use it.
Well it sounds like it can work if you know have enough Linux knowledge 
that if CPAN throws you a curveball (or since you're Australian, bowls 
you a googly?), like package updates clobbering your libraries, and the 
written documentation about what to do is missing or wrong, you can fill 
in the gaps.  I don't know enough about Linux to recognize when the 
documentation is wrong (or to fill in the missing parts), so I try to 
stay on the standard supported path as much as possible.
 Because there were dozens of sources that I read, plus probably
 thousands of others that I didn't read, saying that installing from CPAN
 was a way to install Perl modules, I figured it was reasonably safe to
 follow those directions, so I went ahead and did it.
 Part of the issue is, as others have stated, you have a mish/mash of so many 
 different sources that
 they don't play together nicely any more.
 Best if you pare back to the basics.

 Try just core and EPEL packages to start with. If you can't find a package 
 for your needs you have a
 few options. Compile a package yourself or use CPAN.

 CPAN on CentOS 5 is more difficult because when package updates arrive they 
 can clobber you nicely
 installed CPAN libraries. CentOS 6 handles this better. CPAN does allow you 
 to configure the install
 path for libraries, however, so you can defeat the package update clobberring 
 issue.

 In your case, probably best to stick with the package approach and compile a 
 new package based on
 the installed core and EPEL packages to resolve the rest of your requirements.
I understand (I think), but is it easy to tell me, or is there a 
*reliable*, *vetted* source, describing for intermediate users how to 
actually do this?  i.e.:
1) When you say Try just core and EPEL packages to start with, are you 
talking about which .repo files I should keep in my /etc/yum.repos.d 
directory?  OK, then which ones should be in there?  Only the CentOS-* 
ones that were in there by default?  And *not* the rpmforge.repo one?  
Does one of the default .repo files also include the EPEL packages?
2) And then if I want to install a module like Crypt::Twofish which 
isn't included in the default packages, by compiling a new package 
based on the installed core and EPEL packages, then I do -- what?

I understand that if you already know the answers to these questions, it 
seems like the answers are obvious or easy to find on Google.  The 
problem is that's what got me here in the first place, because I did 
look for answers from reliable sources on Google, and didn't know enough 
to realize which parts of the directions were wrong.  If I try to do the 
next step based on directions from Google, I'm not doing to know when 
the directions are misleading me there either.  So I'm hoping someone 
could tell me how to do it or could point me to directions that have 
actually been vetted (meaning that someone showed the directions to at 
least one intermediate-level user and said Here, we want these 
directions to be helpful to people, so try these out, let me know if you 
get stuck, and we'll keep revising the directions until there are no 
places where people get stuck any more.).

 Now, later I found out that you can get your machine into an
 inconsistent state by installing things from both CPAN and yum
 repositories, and moreover apparently you can't even properly uninstall
 things that are installed by CPAN:
 http://stackoverflow.com/questions/2626449/how-can-i-de-install-a-perl-module-installed-via-cpan
 so by following directions to the letter which are repeated in thousands
 of sources, I apparently put my machine in a state that will cause
 frequent unpredictable conflicts with all the things installed by the
 system package manager, and the damage is irreversible.

 Is that about right? :)

 At about the same time I learned not to use

[CentOS] trouble installing Math::BigInt module

[Bennett Haselton]

I had to move a perl script from an old server to a new one. Both the 
old and new servers are running CentOS release 5.10 (Final) and perl 
v5.8.8.  (But the problem I'm running into appears to be a package 
management problem and not a Perl problem which is why I'm posting it to 
a CentOS list.)

The line of code in the script that attempts to open a Net::SFTP 
connection, which was working fine on the old machine, no longer works 
on the new machine. I've tracked it down to the module 
Net::SSH::Perl::Key::DSA not loading correctly on the new machine. On 
the old one, the line:
perl -e use Net::SSH::Perl::Key::DSA;
gives no error and no output (as expected), but on the new machine, the 
same line gives:

www:/var/www/html/circumventor# perl -e use Net::SSH::Perl::Key::DSA;
Math::BigInt version 1.78 required--this is only version 1.77 at 
/usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4.
BEGIN failed--compilation aborted at 
/usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4.
Compilation failed in require at 
/usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7.
BEGIN failed--compilation aborted at 
/usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7.
Compilation failed in require at 
/usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14.
BEGIN failed--compilation aborted at 
/usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

I tried to install Math::BigInt on my new machine, by adding a file at 
/etc/yum.repos.d/custom.repo containing the lines:

[local]
name=Perl_module
baseurl=http://apt.sw.be/redhat/el5/en/i386/rpmforge/
enabled=1
gpgcheck=0

and then running yum install Math::BigInt, but it just goes through a 
lot of spew and then ends with this error:

 
Transaction Check Error:
file /usr/share/man/man3/Math::BigFloat.3pm.gz from install of 
perl-Math-BigIn
t-1.89-1.el5.rf.noarch conflicts with file from package 
perl-5.8.8-41.el5.i386
file /usr/share/man/man3/Math::BigInt.3pm.gz from install of 
perl-Math-BigInt-
1.89-1.el5.rf.noarch conflicts with file from package perl-5.8.8-41.el5.i386
file /usr/share/man/man3/Math::BigInt::Calc.3pm.gz from install of 
perl-Math-B
igInt-1.89-1.el5.rf.noarch conflicts with file from package 
perl-5.8.8-41.el5.i3
86
file /usr/share/man/man3/Math::BigInt::CalcEmu.3pm.gz from install of 
perl-Mat
h-BigInt-1.89-1.el5.rf.noarch conflicts with file from package 
perl-5.8.8-41.el5
.i386

Error Summary
 

Both servers have Math::BigInt 1.77 installed. As far as I can tell, the 
reason the error occurs on the new server but not on the old server, is 
because on the old server the place that Math::BigInt is loaded is in 
the file /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm which contains the line:
use Math::BigInt;
whereas on the new server, Math::BigInt is loaded in the file 
/usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm which contains 
the line:
use Math::BigInt 1.78 try = 'GMP, Pari';

However, that's where my expertise, such as it is, runs out. I have no 
idea why the two machines even attempt to load Math::BigInt in two 
different ways since I don't remember installing things differently on 
them. I would like to fix the problem on the new machine in the cleanest 
possible way (i.e., not just commenting out the 1.78 in the line use 
Math::BigInt 1.78 -- I don't think that would be the clean solution!).

Any idea what to do?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] trouble installing Math::BigInt module

[Bennett Haselton]

On 3/31/2014 7:56 PM, Tom Robinson wrote:
 Can you verify to which packages thefiles belong?

 Try using RPM:

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm
On the old machine:
perl-Net-IP-1.25-2.fc6
 and

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm
On the new machine:
perl-Crypt-DSA-1.16-1.el5.rf


 Tom Robinson
 IT Manager/System Administrator

 MoTeC Pty Ltd

 121 Merrindale Drive
 Croydon South
 3136 Victoria
 Australia

 T: +61 3 9761 5050
 F: +61 3 9761 5051
 E: tom.robin...@motec.com.au

 On 01/04/14 13:34, Bennett Haselton wrote:
 I had to move a perl script from an old server to a new one. Both the
 old and new servers are running CentOS release 5.10 (Final) and perl
 v5.8.8.  (But the problem I'm running into appears to be a package
 management problem and not a Perl problem which is why I'm posting it to
 a CentOS list.)

 The line of code in the script that attempts to open a Net::SFTP
 connection, which was working fine on the old machine, no longer works
 on the new machine. I've tracked it down to the module
 Net::SSH::Perl::Key::DSA not loading correctly on the new machine. On
 the old one, the line:
 perl -e use Net::SSH::Perl::Key::DSA;
 gives no error and no output (as expected), but on the new machine, the
 same line gives:

 www:/var/www/html/circumventor# perl -e use Net::SSH::Perl::Key::DSA;
 Math::BigInt version 1.78 required--this is only version 1.77 at
 /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4.
 BEGIN failed--compilation aborted at
 /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4.
 Compilation failed in require at
 /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7.
 BEGIN failed--compilation aborted at
 /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7.
 Compilation failed in require at
 /usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14.
 BEGIN failed--compilation aborted at
 /usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14.
 Compilation failed in require at -e line 1.
 BEGIN failed--compilation aborted at -e line 1.

 I tried to install Math::BigInt on my new machine, by adding a file at
 /etc/yum.repos.d/custom.repo containing the lines:

 [local]
 name=Perl_module
 baseurl=http://apt.sw.be/redhat/el5/en/i386/rpmforge/
 enabled=1
 gpgcheck=0

 and then running yum install Math::BigInt, but it just goes through a
 lot of spew and then ends with this error:

   
 Transaction Check Error:
 file /usr/share/man/man3/Math::BigFloat.3pm.gz from install of
 perl-Math-BigIn
 t-1.89-1.el5.rf.noarch conflicts with file from package
 perl-5.8.8-41.el5.i386
 file /usr/share/man/man3/Math::BigInt.3pm.gz from install of
 perl-Math-BigInt-
 1.89-1.el5.rf.noarch conflicts with file from package perl-5.8.8-41.el5.i386
 file /usr/share/man/man3/Math::BigInt::Calc.3pm.gz from install of
 perl-Math-B
 igInt-1.89-1.el5.rf.noarch conflicts with file from package
 perl-5.8.8-41.el5.i3
 86
 file /usr/share/man/man3/Math::BigInt::CalcEmu.3pm.gz from install of
 perl-Mat
 h-BigInt-1.89-1.el5.rf.noarch conflicts with file from package
 perl-5.8.8-41.el5
 .i386

 Error Summary
   

 Both servers have Math::BigInt 1.77 installed. As far as I can tell, the
 reason the error occurs on the new server but not on the old server, is
 because on the old server the place that Math::BigInt is loaded is in
 the file /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm which contains the line:
 use Math::BigInt;
 whereas on the new server, Math::BigInt is loaded in the file
 /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm which contains
 the line:
 use Math::BigInt 1.78 try = 'GMP, Pari';

 However, that's where my expertise, such as it is, runs out. I have no
 idea why the two machines even attempt to load Math::BigInt in two
 different ways since I don't remember installing things differently on
 them. I would like to fix the problem on the new machine in the cleanest
 possible way (i.e., not just commenting out the 1.78 in the line use
 Math::BigInt 1.78 -- I don't think that would be the clean solution!).

 Any idea what to do?

 Bennett
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos



 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] trouble installing Math::BigInt module

[Bennett Haselton]

On 3/31/2014 8:10 PM, John R Pierce wrote:
 On 3/31/2014 7:56 PM, Tom Robinson wrote:
 Can you verify to which packages thefiles belong?

 Try using RPM:

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm

 and

 rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm
 for that matter, on both machines...

   rpm -qa |grep ^perl

Old machine:

perl-Test-Mock-LWP-0.05-1.el5.rf
perl-HTML-Tagset-3.20-1.el5.rf
perl-Net-Daemon-0.43-1.el5.rf
perl-XML-LibXML-1.70-2.el5.rf
perl-Net-SSLeay-1.36-1.el5.rf
perl-DBD-mysql-4.014-1.el5.rf
perl-Crypt-SSLeay-0.57-3.el5.rf
perl-Sub-Uplevel-0.2002-1.el5.rf
perl-IO-Tty-1.08-2.el5.rf
perl-Digest-HMAC-1.01-15
perl-5.8.8-41.el5
perl-libwww-perl-5.805-1.1.1
perl-Test-MockObject-1.09-1.el5.rf
perl-LWP-UserAgent-Determined-1.04-1.el5.rf
perl-Convert-ASN1-0.22-1.el5.rf
perl-UNIVERSAL-can-1.16-1.el5.rf
perl-XML-NamespaceSupport-1.11-1.el5.rf
perl-IO-Compress-2.030-2.el5.rf
perl-Email-Date-Format-1.002-1.el5.rf
perl-Expect-1.21-1.el5.rf
perl-Test-Warn-0.22-1.el5.rf
perl-Net-IP-1.25-2.fc6
perl-WWW-Mechanize-1.72-1.el5.rf
perl-suidperl-5.8.8-41.el5
perl-Net-Telnet-3.03-5
perl-UNIVERSAL-isa-1.03-1.el5.rf
perl-XML-SAX-0.96-1.el5.rf
perl-HTML-Parser-3.68-1.el5.rf
perl-Tree-DAG_Node-1.06-1.el5.rf
perl-Compress-Raw-Bzip2-2.052-1.el5.rf
perl-Compress-Raw-Zlib-2.052-1.el5.rf
perl-Net-DNS-0.59-3.el5
perl-URI-1.35-3
perl-PlRPC-0.2020-1.el5.rf
perl-DBI-1.615-1.el5.rf
perl-HTTP-Server-Simple-0.43-1.el5.rf
perl-Digest-SHA1-2.11-1.2.1
perl-IO-Socket-SSL-1.01-2.el5
perl-MIME-Lite-3.029-1.el5.rf

New machine:

perl-DBD-MySQL-3.0007-2.el5
perl-URI-1.35-3
perl-Compress-Zlib-1.42-1.fc6
perl-String-CRC32-1.4-2.fc6
perl-Tie-EncryptedHash-1.24-1.el5.rf
perl-Sort-Versions-1.5-1.2.el5.rf
perl-File-Which-1.09-1.el5.rf
perl-Class-Loader-2.03-1.2.el5.rf
perl-Net-SSH-Perl-1.34-1.el5.rf
perl-5.8.8-41.el5
perl-Math-Pari-2.01080603-1.el5.rf
perl-Crypt-IDEA-1.08-1.el5.rf
perl-Math-GMP-2.05-1.el5.rf
perl-Crypt-DES-2.05-3.2.el5.rf
perl-Data-Buffer-0.04-1.2.el5.rf
perl-Convert-ASCII-Armour-1.4-1.2.el5.rf
perl-Probe-Perl-0.01-1.el5.rf
perl-Crypt-DH-0.06-1.2.el5.rf
perl-Test-Script-1.05-1.el5.rf
perl-Crypt-DSA-1.16-1.el5.rf
perl-Convert-PEM-0.07-1.2.el5.rf
perl-Crypt-Random-1.25-1.2.el5.rf
perl-Crypt-RSA-1.99-1.el5.rf
perl-Net-SFTP-0.10-1.el5.rf
perl-Crypt-Twofish-2.13-1.el5.rf
perl-DBI-1.52-2.el5
perl-Digest-SHA1-2.11-1.2.1
perl-Digest-MD2-2.03-1.2.el5.rf
perl-Crypt-CBC-2.30-1.el5.rf
perl-Digest-HMAC-1.01-15
perl-IPC-Run3-0.043-1.el5.rf
perl-Convert-ASN1-0.20-1.1
perl-Crypt-Primes-0.50-1.2.el5.rf
perl-suidperl-5.8.8-41.el5

Thanks!

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] bounties for exploits against CentOS?

[Bennett Haselton]

On 1/16/2012 3:13 PM, Eero Volotinen wrote:
 Well I wasn't necessarily advocating it here, just asking whether people
 would feel more or less secure using CentOS if such a prize program
 existed (whether run by CentOS or RHEL), and why or why not.
 Well, no.

 Usually attacks to system are caused by misconfiguration of server or
 firewall or bugs in web applications *)

 *) https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Well one of the lessons of the recent threads seems to be that there is 
a lot of disagreement over what constitutes a misconfigured server.  
Some people consider a server misconfigured if it doesn't use a firewall 
to limit access to sshd, some people consider it misconfigured if sshd 
uses passwords instead of keys, some people consider the server 
misconfigured if it doesn't use SELinux, etc.  Because there are 
mutually contradictory definitions of misconfigured, if you find out 
that a server was broken into you can always come up with a reason, 
after the fact, why the server should be considered misconfigured, 
depending on whose definition you use.

But there seems to be some consensus, at least, that exploits do get 
found which allow apache to run arbitrary code (even under its 
unprivileged account), and exploits do get found that elevate an 
unprivileged user to root privileges.  So you could offer, for example, 
a bounty for anyone who finds a way to elevate the privilege of an 
unprivileged account.  That's a lot less powerful than a complete 
exploit that can be used against any server on the Internet, but it's 
the kind of thing an attacker might use as part of a larger exploit.  So 
would you feel safer using CentOS/Red Hat if Red Hat, for example, 
offered a prize to anyone who could find a privilege-escalation exploit 
like that?  Knowing that it would reduce the chance of a black hat 
finding the exploit and using it as part of an attack?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] bounties for exploits against CentOS?

[Bennett Haselton]

On 1/17/2012 8:11 AM, Les Mikesell wrote:
 On Tue, Jan 17, 2012 at 9:04 AM, Bennett Haseltonbenn...@peacefire.org  
 wrote:
 But there seems to be some consensus, at least, that exploits do get
 found which allow apache to run arbitrary code (even under its
 unprivileged account),
 Web servers are particularly prone to this because webapps are
 typically designed to map user input to some action in a fairly
 flexible way (i.e.by mapping the URL to a program and its inputs) and
 people can easily manipulate the URLs they send.  That leaves a lot of
 levels where buffer overflows or mis-parsing can  let unintended code
 execute.

 and exploits do get found that elevate an
 unprivileged user to root privileges.
 And it is best to assume that there are more that haven't been found...

   So you could offer, for example,
 a bounty for anyone who finds a way to elevate the privilege of an
 unprivileged account.  That's a lot less powerful than a complete
 exploit that can be used against any server on the Internet, but it's
 the kind of thing an attacker might use as part of a larger exploit.  So
 would you feel safer using CentOS/Red Hat if Red Hat, for example,
 offered a prize to anyone who could find a privilege-escalation exploit
 like that?  Knowing that it would reduce the chance of a black hat
 finding the exploit and using it as part of an attack?
 You'll never know when the last bug is found.

Well I'm assuming there is no last bug; rather, that as more and more 
bugs are found and fixed, the mean time to find the next one will get 
measurably larger.

Pretty much all software testing is predicated on this notion -- that as 
you find and fix more bugs (of any kind, not just security bugs), 
eventually the mean time to find the next bug should get larger.  
Otherwise, what's the point, if at the end of all your testing and 
fixing, users keep running into bugs at the same frequency as before?

The idea is that if you find and fix enough of them, eventually the mean 
time to find the next one, and hence the cost of finding the next one, 
will exceed the black-market value of the exploit, so it's no longer 
profitable for black hats to go looking for them.

On the other hand, it is conceivable that above a certain 
effort-threshold, the number of exploits to be found is essentially 
unlimited.  Maybe at the $25,000 level, the number of bugs to be found 
is so large, that no matter how many are found and fixed, the mean time 
to find the next one will always average about $25,000.  Meanwhile, if 
the black-market value of an exploit is more than that (say, $50,000), 
then the black hats will *never* run out of exploits.  This would have 
the unfortunate implication that not only is there no point in paying 
out bounties at that level (since it wouldn't make it any harder for a 
black hat to find a new exploit), but there would be no point in finding 
and fixing exploits at that level at all (unless you know a particular 
exploit is being used in the wild) -- since it will never get any harder 
for a black hat to find one!

 And if you don't know
 that, what have you gained by painting a target on your head?


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] bounties for exploits against CentOS?

[Bennett Haselton]

On 1/17/2012 9:25 AM, Les Mikesell wrote:
 On Tue, Jan 17, 2012 at 11:12 AM, Bennett Haselton
 benn...@peacefire.org  wrote:
 Pretty much all software testing is predicated on this notion -- that as
 you find and fix more bugs (of any kind, not just security bugs),
 eventually the mean time to find the next bug should get larger.
 Otherwise, what's the point, if at the end of all your testing and
 fixing, users keep running into bugs at the same frequency as before?
 Look though the changelogs of any major application or the kernel
 itself.  See if it looks like the world is running out of bugs.


Well if the software itself is constantly being modified in other ways 
(addition of new features) then of course you'll never run out of new 
bugs either :) But even for software where the features are frozen, bugs 
in a given category should eventually get harder to find, and/or should 
be less severe than at the beginning of the cycle (which seemed to be 
the case whenever I worked in testing).

If this were not the case, then what would even be the point of doing 
any testing and bug-fixing at all?  Unless you expect that eventually 
the remaining bugs become rarer or less severe.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] anyone doing automatic yum updates via yum-updatesd on production servers?

[Bennett Haselton]

On 1/17/2012 3:41 PM, Les Mikesell wrote:
 On Tue, Jan 17, 2012 at 2:14 PM, P Jpauljfli...@gmail.com  wrote:
 Thanks for the feedback guys, I agree about best practices but it's nice to
 get direct feedback from your peers.
 In general it is very, very rare for an update to break anything -
 after all that is the whole point of the 'enterprise' distribution and
 it is well tested upstream.  However, it is still possible, especially
 if you have local apps and modifications, and it is very difficult to
 back out any changes the updates make so it is always best to test on
 a similar system before making changes on a production box where
 downtime would be a problem.   For boxes that are internet exposed,
 I'd consider it more dangerous to go for long intervals with no
 updates than to auto-update, though.

That's what I meant hen I said I thought it would be better for CentOS 
to have auto-updates enabled by default out of the box.  Power users can 
always change the defaults.  But for all the servers where the admin 
neglects the server or doesn't know enough to change it -- YES people 
can pontificate all they want about how those people shouldn't be server 
admins -- but the fact being that those servers are out there, it would 
seem less risky to have auto-updates turned on than to have no updates 
at all.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] bounties for exploits against CentOS?

[Bennett Haselton]

With companies like Facebook and Google offering cash prizes for people 
who can find security holes in their products, has there ever been any 
consideration given to offering cash rewards to people finding security 
exploits in CentOS or in commonly bundled services like Apache?  
(Provided of course they follow responsible disclosure and report the 
exploit to the software authors and get it fixed.)

Obviously the benefit would be that it would increase the chance of a 
white hat finding and fixing an exploit, before a black hat discovered 
the same one and used it to attack people's servers.  Would there be any 
other downsides, other than the cost of paying out the prize?

I've heard some objections from companies over the years who didn't want 
to institute a prize program, but I thought some of those objections 
didn't make much sense (and indeed some of those companies ended up 
instituting a prize program after all, a few years later).  For example, 
some people said, This just encourages people to find exploits and then 
they might use those exploits to do harm.  (The problem with this is if 
someone has sufficient black-hat incentives for finding an exploit -- 
either to do malice, or more likely to sell it on the black market -- 
those incentives *already* exist, so the prize program wouldn't create 
any additional incentive to use an exploit illegally.)  Would you feel 
safer using CentOS if a bounty program encouraged people to report 
exploits to the project?  Why or why not?  I think I would, for the 
stated reason -- newly discovered exploits are more likely to get 
reported and fixed, than to be used in the wild.  But I'd be curious why 
anyone might feel less safe if such a program existed.

On a related question, suppose that instead of paying for generic 
exploits against the operating system, you as a webmaster had the option 
of adding your website to a directory of bounty sites, where you would 
have to put up a bond of $100 to join.  Then anyone who could prove that 
they broke into your server (let's say the proof is that they read a 
world-readable file in the root directory) would collect the $100 prize, 
if they can describe exactly how they did it and what you need to fix to 
prevent the attack in the future.  That way, if there's ever a weakness 
in your server, it's more likely to be found by a white hat and reported 
to you directly so you can fix it, before a black hat finds the same 
weakness.  Would you sign up your webserver?  I think I would, and I 
believe I'd be reducing the risk of a black-hat breakin as a result, but 
there may be counter-arguments that I'm not thinking of.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] bounties for exploits against CentOS?

[Bennett Haselton]

On 1/16/2012 12:12 PM, John R Pierce wrote:
 On 01/16/12 10:34 AM, Bennett Haselton wrote:
 With companies like Facebook and Google offering cash prizes for people
 who can find security holes in their products, has there ever been any
 consideration given to offering cash rewards to people finding security
 exploits in CentOS or in commonly bundled services like Apache?
 companies like facebook and google have significant(!!) cash flow.
 centos is a volunteer project.  from where would this prize money come?

 you'd do better addressing this question to Redhat Enterprise Linux,
 anyways, since CentOS's goal is to be a near exact copy, bugs and warts
 included.

Well I wasn't necessarily advocating it here, just asking whether people 
would feel more or less secure using CentOS if such a prize program 
existed (whether run by CentOS or RHEL), and why or why not.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] defense-in-depth possible for sshd?

[Bennett Haselton]

On 1/12/2012 5:25 PM, Johnny Hughes wrote:
 On 01/12/2012 10:31 AM, Tilman Schmidt wrote:
 Am 10.01.2012 19:05, schrieb Johnny Hughes:
 Limit access to the sshd port from only authorized places ... and
 the authorized places can be an openvpn type connection if you
 always need access from difference IPs.  If you have a laptop, put
 an openvpn client on it and take it with you if you need access
 from dynamic places. Connect the openvpn to the endpoint someplace
 and then use  that to connect to the sshd on the server via the
 vpn.
 I'm not convinced that would actually improve security.
 What that does is replace the risk of intrusion via an sshd
 exploit by the risk of intrusion via an OpenVPN exploit.
 But it also adds a layer of complexity, and complexity is
 the enemy of security. So the risk of an exploitable hole
 in OpenVPN would have to be provably so much lower than in
 SSH that the difference outweighs the increase of risk
 through added complexity. I don't know of any data to
 support that claim.
 Not at all ... you first have to crack the OpenVPN system to gain access
 to the ssh port at all (that did not get you into the machine, it got
 you an IP address that then allows you to TRY to access the machine) ...

I think Tilman is saying that rather than cracking OpenVPN in the 
sense of tricking into allowing you access, you could find an exploit in 
OpenVPN where simply sending the right packets to the OpenVPN server 
would allow you to execute arbitrary code as root on the server, the 
same way as an attacker might try to do to the sshd server.

Or is there a reason that an exploit against OpenVPN would be less 
powerful than an exploit against sshd?

This came up earlier, and you said that OpenVPN has had far fewer such 
exploits logged against it than sshd.  In that case it really would be 
more secure, but not because it provides an extra layer, but rather 
simply because exploits against it are more rare.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/10/2012 12:52 PM, 夜神　岩男 wrote:
 On 01/11/2012 05:04 AM, Les Mikesell wrote:
 On Tue, Jan 10, 2012 at 1:46 PM, Daniel J Walshdwa...@redhat.com   wrote:
 On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh
 dwa...@redhat.com   wrote:
 Now if only more people used RHEL we could further enhance
 the products.  :^)

 Why isn't it accepted as more of a standard?

 I don't understand the question.
 Why is it vendor-specific to RHEL?

 I was talking Money not vendor specific. The question meant as a jab
 was if more people used RHEL instead of Centos, we could pay more
 developers.  I thought the @redhat.com would signify why I would want
 that.  :^)
 OK, I can understand why you would want that.  I don't understand why
 you think anyone else would want even more nonstandard variations in
 linux distributions.   And if this isn't intended to be
 vendor-specific, why isn't it an independent upstream project or
 included in the kernel?
 The logical code to SELinux isn't specific to RH, not by a long shot.
 (Of course, RH may wind up doing some way un-Unixy/very-vendor-specific
 things in the near future, but that has nothing to do with SELinux)
 http://userspace.selinuxproject.org/trac
 http://www.gentoo.org/proj/en/hardened/selinux/
 https://wiki.ubuntu.com/SELinux
 ...

 But the difficult thing about SELinux isn't how it works, its the detail
 required for each policy to wrap each program up correctly without
 denying useful functionality in the process, not to mention deploying
 them with packages, and dealing with the whole new universe of
 inaccurate bug reports SELinux has spawned...

 *That* is very hard -- and that is what Red Hat has been so good about
 over the last while. In the process Fedora has spawned a slew of new
 tools to make SELinux policy easier to deal with -- and in the process
 of doing that Fedora acquired/affirmed its reputation for eating babies.

 SElinux exists all over the place, and there are binaries for it in
 nearly every distro -- but nearly everyone has decided that its too
 hard so its just a set of accessory packages almost nobody installs,
 and if installed not activated, and if activated quickly de-activated
 (the #1 web server fix your frustrations on the web advice for noobs
 is still disable SELinux, it sux).

 Honestly, though, at this point the tools really are there. A packager
 that wants to publish an SELinux policy with his package finds it easy
 if the tools are understood -- what is really lacking now is just a very
 public, beginner-friendly introduction to the core concepts of SELinux
 which includes a nice intro to the somewhat arbitrary jargon that
 surrounds access policy concepts.

Well there is already a beginner-friendly introduction:
http://wiki.centos.org/HowTos/SELinux
The problem I had with it is that there are several statements that are 
unclear, missing, or just wrong. That's not necessarily the fault of the 
author; if I had to write an intro to something that I knew a lot about, 
I'd probably also make a few statements that were unclear or wrong.

The cure for that is to show it to 10 people whose intelligence you are 
reasonably confident about, but who *don't already know* what the 
document is trying to teach, and ask them to suggest edits: anything 
that tells the user to do something without saying how, or is unclear, 
or doesn't work when they try it. Then when the documentation has been 
tweaked enough that it no longer has too many of those problem areas, 
then it's ready.

(If I were a volunteer, some of my suggested edits to that page would be:
- Near the beginning the doc says the machine should be rebooted and 
the filesystem relabeled, without telling the user how to actually do 
that. Have a forward-reference telling the user where to read how to 
relabel the filesystem.
- The sentence about Access is only allowed between similar types is 
apparently wrong (and meaningless anyway if it doesn't explain what 
similar types means). I would just go ahead and say that there's no 
way to know for sure what process types will be allowed to access what 
file types, and all you can do is make educated guesses based on the 
similarity of the names, and then look at error logs afterwards to see 
if you were right.
- Explain that files in /tmp/ aren't relabeled after rebooting. (If 
indeed that is the case. We never did figure out why my /tmp/ files 
weren't being relabeled.)
- The genhomedircon command gives an error if SELinux is enforcing; 
switch to permissive before running that command.
- The doc says httpd runs in the httpd_t security context. This is only 
true if it's started silently; if the user starts it from the command 
line, it runs in a different context.)

It doesn't take that much work to turn so-so documentation into really 
useful documentation, but you have to start with the assumption that 
there is room for improvement. The main obstacle is the attitude of 
people like John Dennison, who assume the documentation is fine 

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/11/2012 5:32 AM, 夜神　岩男 wrote:
 On 01/11/2012 07:19 PM, Bennett Haselton wrote:

 Well there is already a beginner-friendly introduction:
 http://wiki.centos.org/HowTos/SELinux
 The problem I had with it is that there are several statements that are
 unclear, missing, or just wrong. That's not necessarily the fault of the
 author; if I had to write an intro to something that I knew a lot about,
 I'd probably also make a few statements that were unclear or wrong.
 Tell me about it. I constantly find myself really great at writing docs
 for systems that the audience is already expert in, but somewhat lacking
 on writing it for complete beginners. Really, the principal problem is
 one of prereqs. Teaching people on this list about SELinux is a lot
 easier than teaching professional diesel mechanics about it, and a bit
 harder than teaching a certain breed of security researchers about it.
 So at what level is appropriate to begin the explanation? This is tricky.

I agree that's always a tricky question, but I think the problem here 
was that even if you knew a lot about Linux but just happened to be 
unfamiliar with SELinux, the documentation was still incorrect in ways 
that the reader wouldn't be able to figure out on their own. When the 
doc says Access is only allowed between similar types, you can't make 
head or tail of that unless you already know what it means.
 The cure for that is to show it to 10 people whose intelligence you are
 reasonably confident about, but who *don't already know* what the
 document is trying to teach, and ask them to suggest edits: anything
 that tells the user to do something without saying how, or is unclear,
 or doesn't work when they try it. Then when the documentation has been
 tweaked enough that it no longer has too many of those problem areas,
 then it's ready.
 This is sounds very much the way open source development works. And its
 the process you're engaging in, actually. See below...
Yes, for software. But I've never heard of it being done for 
documentation. I suspect this is for two reasons: (1) if software fails, 
the dev does has to bite the bullet and make it work, but if 
documentation fails, it's easy to blame the user (reader); (2) to get 
help testing your software, you can stay within the community of people 
who helped right it or those closely connected to them, but to get help 
testing documentation, you have to reach out to people far removed from 
your inner circle. (Plus, in theory you can only test the document on a 
single person one time. You can't use them to test future iterations of 
the same document, because then they might incorrectly report that the 
document is getting clearer when really their understanding is just 
becoming clearer from multiple readings and back-and-forth with the 
authors.)
 (If I were a volunteer, some of my suggested edits to that page would be:
 - Near the beginning the doc says the machine should be rebooted and
 the filesystem relabeled, without telling the user how to actually do
 that. Have a forward-reference telling the user where to read how to
 relabel the filesystem.
 - The sentence about Access is only allowed between similar types is
 apparently wrong (and meaningless anyway if it doesn't explain what
 similar types means). I would just go ahead and say that there's no
 way to know for sure what process types will be allowed to access what
 file types, and all you can do is make educated guesses based on the
 similarity of the names, and then look at error logs afterwards to see
 if you were right.
 - Explain that files in /tmp/ aren't relabeled after rebooting. (If
 indeed that is the case. We never did figure out why my /tmp/ files
 weren't being relabeled.)
 - The genhomedircon command gives an error if SELinux is enforcing;
 switch to permissive before running that command.
 - The doc says httpd runs in the httpd_t security context. This is only
 true if it's started silently; if the user starts it from the command
 line, it runs in a different context.)
 And you should *really* cc this bit to the author. Anyway, you said it
 is a wiki -- so why don't you get to wikifying instead of writing on a
 mailinglist? That's the heart of the process! This is a system under
 development, and as such needs your help. How great would it be for you
 to document your trouble spots in learning and contribute that back?

I wasn't going to get into this, but... I did find the wiki contact 
page, and join their e-mail list, and post to the list asking to create 
an edit account so that I could make an edit (for starters, after the 
sentence about you should re-label the file system, I was going to add 
a link to the steps on how to do that). I got one reply, replied to 
that, and the thread went dead. Here it is:
http://lists.centos.org/pipermail/centos-docs/2012-January/thread.html

Now, I understand if I kept bugging them, they might get back to me, and 
maybe my precious edit would actually happen. I think

[CentOS] SELinux blocking cgi script from writing to socket (httpd_t)

[Bennett Haselton]

Is this really supposed to get easier over time? :)  Now my audit.log 
file shows that SELinux is blocking my cgi script, index.cgi (which is 
what's actually served when the user visits the front page of one of our 
proxy sites like sugarsurfer.com) from having 'read write to socket 
(httpd_t)'.  I have no idea what that means, except that I thought that 
cgi scripts were supposed to be able to write to stdout so that the web 
server could send the data via a socket connection to the end user's 
browser, so I don't know why a CGI script would be blocked from writing 
to a socket with security context httpd_t.

The only clue that might narrow it down is the line Target 
Objectssocket [ udp_socket ].  The sockets that the cgi 
scripts usually send output to are of course tcp sockets, so why would 
it say udp?  The only time one of my cgi scripts might use udp would be 
if it were doing a hostname lookup via dns, but the index.cgi script 
doesn't do that at any point.

What would the pros do at this point?

***

Summary:

SELinux is preventing index.cgi (httpd_sys_script_t) read write to socket
(httpd_t).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux denied access requested by index.cgi. It is not expected that this
access is required by index.cgi and this access may signal an intrusion 
attempt.
It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can 
disable
SELinux protection altogether. Disabling SELinux protection is not 
recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Contextsystem_u:system_r:httpd_sys_script_t
Target Contextsystem_u:system_r:httpd_t
Target Objectssocket [ udp_socket ]
Sourceindex.cgi
Source Path Unknown
Port Unknown
Host Unknown
Source RPM Packages
Target RPM Packages
Policy RPMselinux-policy-2.4.6-316.el5
Selinux Enabled   True
Policy Type   targeted
MLS Enabled   True
Enforcing ModePermissive
Plugin Name   catchall
Host Name g6950-21025.securedservers.com
Platform  Linux g6950-21025.securedservers.com
   2.6.18-274.12.1.el5 #1 SMP Tue Nov 29 
13:37:46 EST
   2011 x86_64 x86_64
Alert Count   1
First SeenWed Jan 11 09:34:13 2012
Last Seen Wed Jan 11 09:34:13 2012
Local ID  2adcd43d-7b8b-4e17-bb93-ad11a35f378a
Line Numbers  1

Raw Audit Messages

type=AVC msg=audit(1326303253.473:3626): avc:  denied  { read write } 
for  pid=6668 comm=index.cgi path=socket:[415055] dev=sockfs 
ino=415055 scontext=system_u:system_r:httpd_sys_script_t:s0 
tcontext=system_u:system_r:httpd_t:s0 tclass=udp_socket

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] missing email

[Bennett Haselton]

On 1/9/2012 10:31 AM, m.r...@5-cent.us wrote:
 I *loathe* dnsorbs Maybe this one will get through its crap. Maybe if
 I add a few more words

 John R. Dennison wrote:
 On Mon, Jan 09, 2012 at 12:49:31PM -0500, m.r...@5-cent.us wrote:
 I haven't gotten anything from the list since my email of 09:34 EST. Do
 I have a problem, or is the list quiet?
 Please cc me offlist, if this goes through.
 I hope you get 20,000 replies :)
 Nope, jes' one, so far.
 snip
 You _could_ just have checked the archive.
 Actually, I went to the archives, and at least saw something from *sigh*
 Bennett that was dated 12:34 or so today; that was why I asked. Dunno if
 someone (NOT my hosting co - I don't have any filtering turned on) is
 delaying, or filtering, or if I'd been dropped for some reason, or


In response to this message from *sigh* Mark, I dug up a bounce message 
that I got when trying to send email to this list yesterday.  The bounce 
indicated that at the time, all mail from Gmail (or at least one 
particular Gmail SMTP server) was being blocked.  I followed the link in 
the bounce message and got the IP of that SMTP server removed from the 
blacklist.

Maybe the blacklist server had temporarly gotten into a state where it 
was reporting all IP addresses as spam sources (not just gmail).  Or 
more generally, if a spam filter is so aggressive that it starts 
blocking all mail from Gmail, it's probably aggressive enough that it 
erratically blocks mail from lots of other sources as well.  (If that 
had been the case though, you presumably would have gotten a bounce 
message like I did.)

Here is the bounce message:

Delivery to the following recipient failed permanently:

  centos-d...@centos.org

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the 
recipient domain. We recommend contacting the other email provider for 
further information about the cause of this error. The error that the 
other server returned was: 554 554 5.7.1 Service unavailable; Client 
host [209.85.210.179] blocked using ix.dnsbl.manitu.net; Your e-mail 
service was detected by mx.selfip.biz (NiX Spam) as spamming at Sun, 08 
Jan 2012 22:02:35 +0100. Your admin should visit 
http://www.dnsbl.manitu.net/lookup.php?value=209.85.210.179 (state 14).

- Original message -


Received: by 10.50.153.234 with SMTP id vj10mr16576276igb.16.1326063636220;
 Sun, 08 Jan 2012 15:00:36 -0800 (PST)

Return-Path: bennetthasel...@gmail.com
Received: from [192.168.1.33] (50-54-225-130.evrt.wa.frontiernet.net. 
[50.54.225.130])

 by mx.google.com with ESMTPS id 
l35sm243526964ibj.0.2012.01.08.15.00.34
 (version=SSLv3 cipher=OTHER);
 Sun, 08 Jan 2012 15:00:35 -0800 (PST)
Sender: Bennett Haselton bennetthasel...@gmail.com
Message-ID: 4f0a2011.1020...@peacefire.org
Date: Sun, 08 Jan 2012 15:00:33 -0800
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] defense-in-depth possible for sshd?

[Bennett Haselton]

If an attacker finds an exploit to take control of httpd, they're still 
blocked in part by the fact that httpd runs as the unprivileged apache 
user and hence can't write any root-owned files on the system, unless 
the attacker also knows of a second attack that lets apache escalate its 
privilege.  Basically correct?

What about sshd -- assuming that the attacker can connect to sshd at all 
(i.e. not prevented by a firewall), if they find an exploit to let them 
take control of sshd, would that imply immediate total control of the 
machine?  Because if they can control sshd they can tell sshd, Allow 
root login (even if prohibited in sshd.conf) and accept 'foo' as the 
password, then the attacker can log in as root.  Is it possible, even 
in theory, to provide a second layer of defense behind sshd to prevent 
the attacker from controlling the machine, if the attacker controls 
sshd?  The log me in as root attack would appear to imply that an 
extra layer is not possible.

(Note I'm not talking about extra layers of security *in front* of sshd, 
like a firewall that only permits logins from known locations.  I'm also 
not talking about detection after the fact -- obviously you can detect 
unexpected root logins from the /var/log/secure* files if the attacker 
doesn't erase them -- only whether you could use extra layers to 
*prevent* the attacker from owning the machine if they take control of 
sshd.)
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] defense-in-depth possible for sshd?

[Bennett Haselton]

On 1/10/2012 2:02 AM, Adrian Sevcenco wrote:
 On 01/10/12 11:12, Bennett Haselton wrote:
 What about sshd -- assuming that the attacker can connect to sshd at all
 (i.e. not prevented by a firewall), if they find an exploit to let them
 take control of sshd, would that imply immediate total control of the
 UsePrivilegeSeparation
 Specifies whether sshd(8) separates privileges by creating an 
 unprivileged child process to deal with incoming network traffic. 
 After successful authentication, another process will be created that 
 has the privilege of the authenticated user.  The goal of privilege 
 separation is to prevent privilege escalation by containing any 
 corruption within the unprivileged processes.  The default is ``yes''. 
 If UsePrivilegeSeparation is set to ``sandbox'' then the 
 pre-authentication unprivileged process is subject to additional 
 restrictions.

 http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_configsektion=5
OK.  So it sounds like if you found a particular exploit in sshd that 
could *only* do certain things -- like write a file to an arbitrary 
location on disk -- then this privilege separation would prevent that 
exploit from being used to make the child process write somewhere that 
it didn't have privileges to write to.

On the other hand if you found an exploit that let you take complete 
control of sshd, you could just tell it allow logins from root, accept 
'foo' as the password, and then do whatever you were going to do 
before, and that would presumably work, wouldn't it?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] defense-in-depth possible for sshd?

[Bennett Haselton]

On 1/10/2012 5:16 AM, John Doe wrote:
 From: Bennett Haseltonbenn...@peacefire.org

 On 1/10/2012 2:02 AM, Adrian Sevcenco wrote:
   UsePrivilegeSeparation
   Specifies whether sshd(8) separates privileges by creating an
   unprivileged child process to deal with incoming network traffic.
   After successful authentication, another process will be created that
   has the privilege of the authenticated user.  The goal of privilege
   separation is to prevent privilege escalation by containing any
   corruption within the unprivileged processes.  The default is
 ``yes''.
 OK.  So it sounds like if you found a particular exploit in sshd that
 could *only* do certain things -- like write a file to an arbitrary
 location on disk -- then this privilege separation would prevent that
 exploit from being used to make the child process write somewhere that
 it didn't have privileges to write to.
 Do a ps and look at the sshd tree.  Example:
 root  6014  0.0  0.1  97816  3760 ?S11:01   0:00  \_ sshd: 
 bob [priv]
 bob   6029  0.0  0.0  97816  1796 ?S11:01   0:00  \_ 
 sshd: bob@pts/2
 bob   6030  0.0  0.0 108392  1760 pts/2Ss   11:01   0:00  \_ 
 -bash

 The sshd child is running as bob; so it has bob (and not root) rights...

 JD

Yes, I understand that.  What I said was that if you could take complete 
control of the sshd process you were connecting to, even if that process 
was completely unprivileged, you could still make it say Accept a login 
from 'root' with password 'foo' and then log in as root.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/9/2012 8:05 PM, Marko Vojinovic wrote:
 On Monday 09 January 2012 15:29:59 Daniel J Walsh wrote:
 file_t means the file has no label, so the only way to create this
 type of file would be to remove the security attributes on the file.
 On an SELinux system, file_t should never be created, they are only
 created on a disabled SELinux system.  I guess you could try to use
 chcon -t file_t on a file, but I believe the kernel will block that.
 Or you could attempt to delete the SELinux label, but that might also
 be denied.
 Ok, now I think I understand. The OP has stale files in /tmp which are not
 labelled, due to not purging /tmp on reboot. SELinux doesn't know how these
 files should be labelled, so it doesn't even try, and gives them the type
 file_t, which is a synonym for this file doesn't have a type.

 So the answer for the OP is to use chcon on this file to label it somehow. If
 that doesn't work, he should delete the file and recreate it (while SELinux is
 active), so that it gets properly labelled.

OK, I did delete the files in the /tmp/ directory, and as the running 
apache process re-created them, it created them with the correct type:
[root@g6950-21025 tmp]# ls -lZ *
-rw-r--r--  apache apache system_u:object_r:httpd_sys_script_rw_t 
hostname_ICECOOK.INFO
-rw-r--r--  apache apache system_u:object_r:httpd_sys_script_rw_t 
hostname_LAZYFROG.INFO
etc.

So the documentation is missing something about clearing files out of 
/tmp/ (or they won't get relabeled properly and processes won't be able 
to access them under SELinux), but at least it's working now.

Bennett

 I learned something new today. :-) Thanks for the explanation!

 Best, :-)
 Marko


 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/9/2012 3:41 AM, Tony Molloy wrote:
 On Sunday 08 January 2012 23:19:39 Bennett Haselton wrote:
 On 1/8/2012 7:28 AM, Ljubomir Ljubojevic wrote:
 On 01/08/2012 03:15 PM, Bennett Haselton wrote:
 It's a file created by one of my CGI scripts.  (The web server
 is accessed by several hostnames which are dynamically assigned
 to it, and I need a quick way of determining all hostnames that
 were recently used to access the server.  So when someone
 accesses the server using HOSTNAME, the file
 /tmp/hostname_hostnameis created.  Then another script
 just pulls the names of all of those files in order to find all
 recently used hostnames.)

 My suggestion:

 stop apache
 run relabeling again (if file continues to exists)
 start apache
 check
 Well when I was doing the relabeling I was doing:
 # touch /.autorelabel
 # reboot

 So when I'm rebooting apache stops and starts anyway, doesn't
 it? Doesn't the auto-relabel occur before other services are
 started up?  So I'm not sure what I would actually do
 differently to follow this suggestion...
 Ah, you are write, sorry. Well you might need to apply proper
 (httpd_) SELinux label for that file. At the time of creation? \
 Maybe move it to another location where it will get automatic
 label for what you want?
 Well the warning messages say that file_t files should *never* get
 created if the filesystem is labeled properly.  So I didn't think
 it was just a matter of creating files where the default filetype
 would be different, because the default filetype should not be
 file_t anywhere.

 I could create a world-writeable directory somewhere else and have
 all the scripts write to that but it would be a pain to re-write
 and re-test everything as a workaround for this one bug...

 Well, one other theory: /tmp is a different partition, right?  So
 maybe when I do
 # touch /.autorelabel
 # reboot

 it's only re-labeling the / partition and not the /tmp one?
 Unfortunately in that case I don't know how to make it re-label the
 /tmp filesystem as well.  I tried creating /tmp/.autorelabel and
 rebooting, but that didn't work; /tmp/hostname_SKYSLICE.INFO and
 other files still had type file_t.

 Bennett
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 First I'm no SELinux expert ;-( but I've ben following this thread
 with interest. It apears to be going around in circles.

 The only time I've come across a file_t type is when I have something
 on a machine that SELinux doesn't know about. That is SELinux has no
 policy for it. An example would be if I create a new top level
 directory when I install a machine. SELinux knows nothing about that
 directory name and has no preset type for it so it gets a label of
 file_t or default_t. Doing a relabel in that case will have no affect on
 the file label as SELinux still doesn't have a policy for it.

 So the question is how did your file get the file_t type in the first
 place. You say it is generated from a cgi script run from apache.

 So is this the default apache which comes with CentOS

 What is the context of the apache executable. It should be
 -rwxr-xr-x  root root system_u:object_r:httpd_exec_t   /usr/sbin/httpd
Yes that's what I've got.
 Where in the filesystem is the cgi script located. How did it get
 there.

 What is the context of the cgi script

 What is the context of the directory the cgi script is in.
[root@g6950-21025 ~]# ls -lZ /var/www/cgi-bin/capture.cgi
-rwxr-xr-x  root root system_u:object_r:httpd_sys_script_exec_t 
/var/www/cgi-bin/capture.cgi
[root@g6950-21025 ~]# ls -ldZ /var/www/cgi-bin/
drwxr-xr-x  root root system_u:object_r:httpd_sys_script_exec_t 
/var/www/cgi-bin/

The script got there because I uploaded it there.
 What is the context of /tmp. It should be
 drwxrwxrwt  root root system_u:object_r:tmp_t  /tmp
Yep.
[root@g6950-21025 ~]# ls -ldZ /tmp
drwxrwxrwt  root root system_u:object_r:tmp_t  /tmp
 Regards

 Tony
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 7:49 PM, Marko Vojinovic wrote:
 On Saturday 07 January 2012 17:23:57 Bennett Haselton wrote:
 [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO
 -rw-r--r--  apache apache system_u:object_r:file_t
 /tmp/hostname_SKYSLICE.INFO

 Any ideas?
 What does

 # restorecon -v /tmp/hostname_SKYSLICE.INFO

 return?
No output, and then the file type is the same as before:

[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO
-rw-r--r--  apache apache system_u:object_r:file_t 
/tmp/hostname_SKYSLICE.INFO
[root@g6950-21025 ~]# restorecon -v /tmp/hostname_SKYSLICE.INFO
[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO
-rw-r--r--  apache apache system_u:object_r:file_t 
/tmp/hostname_SKYSLICE.INFO
[root@g6950-21025 ~]#


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 6:25 PM, Gordon Messmer wrote:
 On 01/06/2012 01:36 AM, Bennett Haselton wrote:
 So I still don't know: after creating /.autorelabel (and verifying that
 it's there), and rebooting the system (and then verifying that the
 /.autorelabel file has been deleted, which is supposed to mean the
 auto-relabel actually happened), why am I still seeing the file type
 listed as file_t?
 Either SELinux is disabled or your filesystem doesn't support extended
 attributes.
[root@g6950-21025 ~]# sestatus
SELinux status: enabled
SELinuxfs mount:/selinux
Current mode:   permissive
Mode from config file:  permissive
Policy version: 21
Policy from config file:targeted

(same thing happens if I switch to enforcing, although then things 
start breaking instead of logging warnings)

 Check /proc/cmdline to see if the kernel was instructed to disable
 SELinux

[root@g6950-21025 ~]# cat /proc/cmdline
ro root=/dev/sys-0n1f/root

Not sure what that means but I assume it doesn't force SELinux to be 
disabled.

 and check /etc/sysconfig/selinux.

[root@g6950-21025 ~]# cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#   enforcing - SELinux security policy is enforced.
#   permissive - SELinux prints warnings instead of enforcing.
#   disabled - SELinux is fully disabled.
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
#   targeted - Only targeted network daemons are protected.
#   strict - Full SELinux protection.
SELINUXTYPE=targeted
[root@g6950-21025 ~]#


Note: SELinux is logging warnings (while in permissive mode) to 
/var/log/audit/audit.log whenever httpd interacts with one of the files 
like /tmp/hostname_SKYSLICE.INFO . Presumably that means it's not 
disabled; SELinux is on, but the file still hasn't been relabeled.

 Check /proc/mounts to see what filesystem type your system is using.
[root@g6950-21025 ~]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
/dev /dev tmpfs rw 0 0
/proc /proc proc rw 0 0
/sys /sys sysfs rw 0 0
none /selinux selinuxfs rw 0 0
/proc/bus/usb /proc/bus/usb usbfs rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/sys-0n1f/vartmp /var/tmp ext3 rw,nosuid,noexec,data=ordered 0 0
/dev/sys-0n1f/tmp /tmp ext3 rw,nosuid,noexec,data=ordered 0 0
/dev/sda1 /boot ext3 rw,data=ordered 0 0
tmpfs /dev/shm tmpfs rw,nosuid,noexec 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
/etc/auto.misc /misc autofs 
rw,fd=7,pgrp=2217,timeout=300,minproto=5,maxproto=5,indirect 0 0
-hosts /net autofs 
rw,fd=13,pgrp=2217,timeout=300,minproto=5,maxproto=5,indirect 0 0
 Use tune2fs -l to see if an ext3/4 filesystem has the user_xattr option.
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
In the output above,
/dev/root
/dev/sys-0n1f/vartmp
/dev/sys-0n1f/tmp
/dev/sda1

were all listed as ext3, and when I ran tune2fs -l on each of them, 
the output included the line
Default mount options:user_xattr acl

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/8/2012 5:36 AM, Ljubomir Ljubojevic wrote:
 On 01/08/2012 02:10 PM, Marko Vojinovic wrote:
 [root@g6950-21025 ~]# restorecon -v /tmp/hostname_SKYSLICE.INFO
   [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO
   -rw-r--r--  apache apache system_u:object_r:file_t
   /tmp/hostname_SKYSLICE.INFO
   [root@g6950-21025 ~]#
 Well...

 With this output I would say that your policy has been customized to have
 file_t as the default label for that file. Have you used audit2allow on that
 machine before the filesystem was properly relabeled?
 That file is in the /tpm folder, used by apache. I guess that apache was
 not stopped since/during relabeling so it stayed.
It's a file created by one of my CGI scripts.  (The web server is 
accessed by several hostnames which are dynamically assigned to it, and 
I need a quick way of determining all hostnames that were recently used 
to access the server.  So when someone accesses the server using 
HOSTNAME, the file /tmp/hostname_hostname is created.  Then another 
script just pulls the names of all of those files in order to find all 
recently used hostnames.)
 My suggestion:

 stop apache
 run relabeling again (if file continues to exists)
 start apache
 check

Well when I was doing the relabeling I was doing:
# touch /.autorelabel
# reboot

So when I'm rebooting apache stops and starts anyway, doesn't it?  
Doesn't the auto-relabel occur before other services are started up?  So 
I'm not sure what I would actually do differently to follow this 
suggestion...
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/8/2012 7:28 AM, Ljubomir Ljubojevic wrote:
 On 01/08/2012 03:15 PM, Bennett Haselton wrote:
 It's a file created by one of my CGI scripts.  (The web server is
 accessed by several hostnames which are dynamically assigned to it, and
 I need a quick way of determining all hostnames that were recently used
 to access the server.  So when someone accesses the server using
 HOSTNAME, the file /tmp/hostname_hostname   is created.  Then another
 script just pulls the names of all of those files in order to find all
 recently used hostnames.)
 My suggestion:

 stop apache
 run relabeling again (if file continues to exists)
 start apache
 check
 Well when I was doing the relabeling I was doing:
 # touch /.autorelabel
 # reboot

 So when I'm rebooting apache stops and starts anyway, doesn't it?
 Doesn't the auto-relabel occur before other services are started up?  So
 I'm not sure what I would actually do differently to follow this
 suggestion...
 Ah, you are write, sorry. Well you might need to apply proper (httpd_)
 SELinux label for that file. At the time of creation? \
 Maybe move it to another location where it will get automatic label for
 what you want?

Well the warning messages say that file_t files should *never* get 
created if the filesystem is labeled properly.  So I didn't think it was 
just a matter of creating files where the default filetype would be 
different, because the default filetype should not be file_t anywhere.

I could create a world-writeable directory somewhere else and have all 
the scripts write to that but it would be a pain to re-write and re-test 
everything as a workaround for this one bug...

Well, one other theory: /tmp is a different partition, right?  So maybe 
when I do
# touch /.autorelabel
# reboot

it's only re-labeling the / partition and not the /tmp one?  
Unfortunately in that case I don't know how to make it re-label the /tmp 
filesystem as well.  I tried creating /tmp/.autorelabel and rebooting, 
but that didn't work; /tmp/hostname_SKYSLICE.INFO and other files still 
had type file_t.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 4:16 AM, Marko Vojinovic wrote:
 On Friday 06 January 2012 18:27:05 Bennett Haselton wrote:
 On 1/6/2012 6:16 PM, RILINDO FOSTER wrote:
 On Jan 6, 2012, at 10:35 AM, Bennett Haselton wrote:
 I'm pretty sure this machine was never upgraded to CentOS 5.2, it
 was
 just imaged with 5.7 when the hosting company set it up, but SELinux
 *was* off until I turned it on.  So probably the doc should say, if
 the
 system was *installed* with 5.2, then do this (and presumably it's
 5.2
 or later, not just 5.2).
 Either that, or the base install was an earlier version of Centos 5.x,
 with SELinux turned off then upgraded to the current version.
 Could be in theory but if the hosting company was provisioning a new
 machine I don't know why they'd set up an earlier version and then
 upgrade, instead of just imaging the latest version at the time.
 How about --- the hosting company installs CentOS once (the 5.2 version) as
 their master image, turns off SELinux, and keeps updating the image over time?
 And when a customer asks for a new machine, they just make a copy of the
 current state of the master image? I guess that would be much easier (for
 them), compared to actually installing the latest version of CentOS from
 scratch, for every customer.

 Why don't you ask the hosting company exactly what kind of system did they
 provide to you? Since SELinux was off by default, it certainly is not just a
 default installation of CentOS 5.7 (nor any other version of CentOS). They
 obviously made some manual after-install customizations before they handed you
 the system.

 IMHO, if a hosting company does that sort of things (especially turning off
 SELinux), I wouldn't touch them with a ten-foot pole. Who knows what else they
 might have customized, in their infinite wisdom... :-)

 Care to share the name of that hosting company?

Virtually every hosting company I've ever bought a CentOS server from 
has had SELinux turned off by default.  (So, a partial list would 
include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), 
AeroVPS (sells dedicated servers despite their name), Netelligent, 
ServerBeach and I don't remember all the others).  Don't hold me to that 
list 100% since some might have changed their policies for new servers 
but it's pretty universal.

What hosting company sells sub-$100 unmanaged CentOS dedicated servers 
and *doesn't* have SELinux turned off?

 As for the original question -- when the docs say that access is allowed
 only across similar types, what determines what counts as similar
 types?  How do you know for example that httpd running as type httpd_t
 can access /var/www/html/robots.txt which has type httpd_sys_content_t?
 AFAIK, the interactions between various labels (ie. rules who can access
 what) are determined by the SELinux targeted policy (the selinux-policy-
 targeted package). These rules evolve over time (the package sometimes gets
 updated and your filesystem autorelabeled to match), and IIRC they can get
 pretty complicated. You want to look inside that package to find all the 
 rules.
OK.  Is it easy to look inside the package and where would I look?
 But in usual circumstances you shouldn't need to know any details, just let
 the system label the files as they are supposed to be labeled, and everything
 should Just Work (tm). If you need to customize something, you can use
 semanagerestorecon to override the default policy.

 HTH, :-)
 Marko


 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 5:25 AM, John R. Dennison wrote:
 On Sat, Jan 07, 2012 at 04:43:31AM -0800, Bennett Haselton wrote:
 Virtually every hosting company I've ever bought a CentOS server from
 has had SELinux turned off by default.  (So, a partial list would
 include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho),
 AeroVPS (sells dedicated servers despite their name), Netelligent,
 ServerBeach and I don't remember all the others).  Don't hold me to that
 list 100% since some might have changed their policies for new servers
 but it's pretty universal.
 Then these companies should be universally boycotted as it's pretty
 evident that they don't place security at the top of the importance
 stack.

 People that don't run selinux deserve _everything_ they get and then
 some.
I remember the same attitude around 2000 and earlier, towards people who 
spread viruses on Windows.  The attitude was that people should just 
learn about their OS (in particular, what types of actions were likely 
to get you infected), and it wasn't anyone else's responsibility to 
work around it.  And the problem kept getting worse.

Then there seemed to be a sea change in attitudes toward the problem -- 
the realization that complaining about human nature was not going to do 
any good, and if the marketplace favored selling machines to people who 
were not highly computer-literate, it was going to happen.  Making value 
judgments about what people should and should not do, did about as 
much good as complaining about the sun coming up in the morning.

So an effort was made to change *default* behaviors so that computers 
would not do bone-headed things even in the hands of bone-headed users.  
Email servers started scanning for viruses, email programs started 
giving more and scarier warnings about opening executable attachments, 
ISPs started bundling anti-virus software, etc. (All of these things 
were already on the rise, of course.)

And that rolled the problem back a bit.  Not complaining about what 
people should know, which never had a chance of working, but changing 
default behaviors to take into account the fact that most people did not 
know what the gurus think everyone should know.  (Of course attackers 
didn't go away, but switched to trickier methods like browser exploits, 
which will work even on sophisticated users.)

What you think people should know is a matter of opinion.  However, 
complaining about what people should know, usually doesn't do any 
good, and that's an empirical fact, not an opinion.

Apparently the marketplace favors hosting companies turning SELinux off 
because the failures it causes are too obscure and it causes too many 
support headaches.  A non-changing-human-nature solution might be to 
notify the user directly when SELinux blocks something.  The GUI 
apparently already does this via a dialog box when viewing a desktop; 
perhaps there's a way to do it on the command line too.  (When the user 
runs something that's blocked by SELinux, just send a message to the 
terminal saying SELinux blocked this, or something.  Would be a start.)

 By the way, please learn how to properly respond to a public mailing
 list by trimming unnecessary response content.
Nobody else was trimming.  When in Rome :)  (By definition, a 
quoted-quoted-quoted message can only keep getting longer if nobody else 
is trimming either.)

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 5:57 AM, Marko Vojinovic wrote:
 On Saturday 07 January 2012 04:43:31 Bennett Haselton wrote:
 On 1/7/2012 4:16 AM, Marko Vojinovic wrote:
 IMHO, if a hosting company does that sort of things (especially turning
 off SELinux), I wouldn't touch them with a ten-foot pole. Who knows
 what else they might have customized, in their infinite wisdom... :-)

 Care to share the name of that hosting company?
 Virtually every hosting company I've ever bought a CentOS server from
 has had SELinux turned off by default.  (So, a partial list would
 include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho),
 AeroVPS (sells dedicated servers despite their name), Netelligent,
 ServerBeach and I don't remember all the others).  Don't hold me to that
 list 100% since some might have changed their policies for new servers
 but it's pretty universal.

 What hosting company sells sub-$100 unmanaged CentOS dedicated servers
 and *doesn't* have SELinux turned off?
 I wouldn't know, I don't use such services (typically I have my production
 systems on my own hardware). And now that you say most of them turn SELinux 
 off
 by default, I am discuraged to even consider having my system hosted by such
 companies... ;-)

 As for the original question -- when the docs say that access is
 allowed
 only across similar types, what determines what counts as similar
 types?  How do you know for example that httpd running as type
 httpd_t
 can access /var/www/html/robots.txt which has type
 httpd_sys_content_t?
 AFAIK, the interactions between various labels (ie. rules who can
 access
 what) are determined by the SELinux targeted policy (the
 selinux-policy-
 targeted package). These rules evolve over time (the package sometimes
 gets updated and your filesystem autorelabeled to match), and IIRC they
 can get pretty complicated. You want to look inside that package to
 find all the rules.
 OK.  Is it easy to look inside the package and where would I look?
 Well, a rpm -ql selinux-policy-targeted lists a whole bunch of files, mostly
 all residing under /etc/selinux/targeted/ directory. So you can take a look at
 what is in there. If that is not enough (ie. if you want to look inside the
 binary modules), you'll probably want to read the corresponding srpm. Use the
 Source, Luke! ;-)

 Btw, your question is about some quite low-level-inside-guts of the SELinux
 policy. I cannot imagine why you would want to know the detailed relationships
 between labels, unless you are a SELinux developer. Or is it just curiosity?
I think it's because the doc page said Access is allowed only between 
similar types and I took that to mean that I should look at the type of 
a process and the type of a file to figure out if something was going to 
be allowed, if writing a script to do something unusual and hoping for 
it to work under SELinux.

However, maybe the more useful answer is that because SELinux's error 
reporting is so thorough and human-readable -- you can convert every 
error message into a mini-article using audit2allow or sealert, telling 
you exactly what to do -- that you don't need to code defensively, you 
can just run a program, see what errors are logged, and look at the 
report to see exactly what needs to be changed.  This takes some getting 
used to since SELinux is the only thing I've seen that comes with tools 
to explain its error messages so helpfully.  Everything else, the error 
messages are usually so obscure that it's easier to code defensively and 
follow guidelines for what you know *will* work.
 HTH, :-)
 Marko


 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 6:50 AM, Marko Vojinovic wrote:
 On Saturday 07 January 2012 05:39:15 Bennett Haselton wrote:
 On 1/7/2012 5:25 AM, John R. Dennison wrote:
 On Sat, Jan 07, 2012 at 04:43:31AM -0800, Bennett Haselton wrote:
 Virtually every hosting company I've ever bought a CentOS server from
 has had SELinux turned off by default.  (So, a partial list would
 include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho),
 AeroVPS (sells dedicated servers despite their name), Netelligent,
 ServerBeach and I don't remember all the others).  Don't hold me to
 that
 list 100% since some might have changed their policies for new servers
 but it's pretty universal.
 Then these companies should be universally boycotted as it's pretty
 evident that they don't place security at the top of the importance
 stack.

 People that don't run selinux deserve _everything_ they get and then
 some.
 [snip]
 Apparently the marketplace favors hosting companies turning SELinux off
 because the failures it causes are too obscure and it causes too many
 support headaches.
 Ignorance is bliss... ;-)

 A hosting company should certainly have SELinux turned on by default. A
 customer who doesn't know how to handle it should be told to RTFM.
See what I wrote to John about should-statements... you can't change 
human nature, but you can make better defaults.
 If they
 don't want to deal with SELinux, they can easily turn it off themselves (at
 their own responsibility).

 This is analogous to having a rent-a-car agency renting cars without safety
 belts, because they are inconvenient for the users and most people don't put
 them on anyway. Being irresponsible cannot be justified with what marketplace
 does or does not favor.

 A non-changing-human-nature solution might be to
 notify the user directly when SELinux blocks something.  The GUI
 apparently already does this via a dialog box when viewing a desktop;
 perhaps there's a way to do it on the command line too.  (When the user
 runs something that's blocked by SELinux, just send a message to the
 terminal saying SELinux blocked this, or something.  Would be a start.)
 Sometimes there is a message on stderr about permission denied or such. But
 in general every AVC denial is written in /var/log/audit/audit.log. There are
 also setroubleshootd and sealert, to help you translate the AVC denial into
 something more user-friendly, and suggest what to do about it.

Yes, once you know that SELinux is the cause, the tools for diagnosing 
what to do are pretty helpful.  But what hosting companies care about -- 
in terms of inconvenience to the user -- is that there's no easy way to 
find out for the first time that SELinux is the cause of something not 
working.

Hence the idea for having SELinux send messages to the terminal saying 
SELinux blocked such-and-such.  There's probably some better way.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 9:58 AM, John R. Dennison wrote:
 On Sat, Jan 07, 2012 at 09:09:45AM -0800, Bennett Haselton wrote:
 OK, I followed the instructions at
 http://wiki.centos.org/HowTos/SELinux
 for re-labeling the filesystem and it did not work.  Why not?  Since you
 said you had no issues figuring it out.
 It did not work _how_?  How did it fail?  What was on the console
 during the relabel?

 I've never had a relabel fail.  YMMV.


I've posted several messages about this, but to sum up the current state 
of the problem:

This is a remotely hosted machine so I don't know what's coming up on 
the console.  But ls -lZ reports several files of type file_t, such as:
[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO
-rw-r--r--  apache apache system_u:object_r:file_t 
/tmp/hostname_SKYSLICE.INFO

sealert says that a file_t filetype means the relabel failed:
 
Summary:

SELinux is preventing access to files with the label, file_t.

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux permission checks on files labeled file_t are being denied. 
file_t is
the context the SELinux kernel gives to files that do not have a label. This
indicates a serious labeling problem. No files on an SELinux box should 
ever be
labeled file_t. If you have just added a new disk drive to the system 
you can
relabel it using the restorecon command. Otherwise you should relabel 
the entire
files system.

Allowing Access:

You can execute the following command as root to relabel your computer 
system:
touch /.autorelabel; reboot
 

So, I ran the touch /.autorelabel; reboot commands but that didn't fix 
it.  Then I read at
http://wiki.centos.org/HowTos/SELinux
that sometimes this isn't enough if the machine has been upgraded from 
an old CentOS version, so I ran
# genhomedircon
# touch /.autorelabel
# reboot

but that still didn't fix it as I still get:
[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO
-rw-r--r--  apache apache system_u:object_r:file_t 
/tmp/hostname_SKYSLICE.INFO

Daniel suggested running fixfiles restore, which I did, and got this 
output:
 
[root@g6950-21025 ~]# fixfiles restore
/sbin/setfiles:  labeling files under /
***
***matchpathcon_filespec_eval:  hash table stats: 
98376 elements, 30515/65536 buckets used, longest
chain length 18
/sbin/setfiles:  labeling files under /var/tmp
matchpathcon_filespec_eval:  hash table stats: 2 elements, 2/65536 
buckets used, longest chain length 1
/sbin/setfiles:  labeling files under /tmp
matchpathcon_filespec_eval:  hash table stats: 19 elements, 19/65536 
buckets used, longest chain length 1
/sbin/setfiles:  labeling files under /boot
matchpathcon_filespec_eval:  hash table stats: 44 elements, 44/65536 
buckets used, longest chain length 1
/sbin/setfiles:  Done.
 

and I rebooted for good measure, but I still get:
[root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO
-rw-r--r--  apache apache system_u:object_r:file_t 
/tmp/hostname_SKYSLICE.INFO

Any ideas?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/7/2012 9:41 AM, Marko Vojinovic wrote:
 On Saturday 07 January 2012 08:15:35 Bennett Haselton wrote:
 On 1/7/2012 6:50 AM, Marko Vojinovic wrote:
 On Saturday 07 January 2012 05:39:15 Bennett Haselton wrote:
 Apparently the marketplace favors hosting companies turning SELinux
 off
 because the failures it causes are too obscure and it causes too many
 support headaches.
 Ignorance is bliss... ;-)

 A hosting company should certainly have SELinux turned on by default. A
 customer who doesn't know how to handle it should be told to RTFM.
 See what I wrote to John about should-statements... you can't change
 human nature, but you can make better defaults.
 What do you mean by better defaults? Better for the user, or better for the
 hosting company? Better in terms of quality/security, or better in terms of
 ease of use?

 There is no obvious better default, IMHO. This is about trading security for
 convenience, and if a hosting company puts convenience before security, they
 are doing a lousy job. Turning off SELinux is a choice that should be done by
 the *customer*, not by the hosting company.

 I am still waiting for the day when SELinux will become completely mandatory,
 just as the owner/group permissions are today. ;-)

 Sometimes there is a message on stderr about permission denied or
 such. But in general every AVC denial is written in
 /var/log/audit/audit.log. There are also setroubleshootd and sealert,
 to help you translate the AVC denial into something more
 user-friendly, and suggest what to do about it.
 Yes, once you know that SELinux is the cause, the tools for diagnosing
 what to do are pretty helpful.  But what hosting companies care about --
 in terms of inconvenience to the user -- is that there's no easy way to
 find out for the first time that SELinux is the cause of something not
 working.

 Hence the idea for having SELinux send messages to the terminal saying
 SELinux blocked such-and-such.  There's probably some better way.
 Well, when something gets blocked by iptables, that doesn't even get into a
 log, let alone interactive messages. An administrator needs to be intelligent
 enough to *guess* that the app doesn't work because some port might be closed
 by the firewall. That's even worse than the situation with SELinux, and nobody
 has ever fixed that one in decades. :-)

Well, yes there would be fewer usability issues if it did send a message 
to the user.  Although, a firewall is something that a user might be 
more likely to guess about, because firewalls exist on every OS and have 
for a  long time, but SELinux is Linux-only and apparently only one some 
distros.

 I guess it could be easily implemented, though. All AVC denials are being
 communicated via dbus, and can probably be caught and sent to a terminal as
 well. Read man audispd and related stuff --- I guess one can customize the
 relevant log daemon to send messages to the terminal too, in addition to the
 log file.

 If you manage to customize it, send us the recipe, I guess it could be helpful
 for others as well. :-)


I don't need it for myself, now that I know to look in the logs :) The 
point was to make it more discoverable for users who may not realize 
it's turned on and why their new server app isn't working.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/5/2012 4:37 PM, Bennett Haselton wrote:
 On 1/5/2012 3:14 PM, RILINDO FOSTER wrote:
 On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/05/2012 04:36 PM, Bennett Haselton wrote:
 http://wiki.centos.org/HowTos/SELinux says: Access is only allowed
 between similar types, so Apache running as httpd_t can read
 /var/www/html/index.html of type httpd_sys_content_t.

 however the doc doesn't define what similar types means.  I
 assumed it just meant beginning with the same prefix.  However
 that can't be right because on my system with SELinux turned on,
 httpd runs as type init_t:

 [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
 system_u:system_r:init_t:s0 root  2521  0.1  0.4  21680
 8820 ?Ss   05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2550  0.0  0.4  23364
 8920 ?S05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2551  0.1  0.4  22736
 8212 ?S05:05   0:00 /usr/sbin/httpd

 and the robots.txt file has type file_t: [root@peacefire04 - /root
 # ls -lZ /var/www/html/robots.txt -rw-rw-rw-  root root
 system_u:object_r:file_t:s0 /var/www/html/robots.txt

 but Apache can of course access that file.  So in Type Enforcement,
 what determines what process type can access what file type?

 Bennett ___ CentOS
 mailing list CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

 Your machine needs to be relabeled.

 touch /.autorelabel
 reboot
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5
 lFkAnjLTi3zphekGomv04ZyMu0sOuopg
 =cIvM
 -END PGP SIGNATURE-
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 WARNING: If you have never enabled SELinux for long time, the boot is 
 going to take a while as the system relabels the whole machine. Do 
 not do this unless you can plan for an extend downtime.

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 I did do
 touch /.autorelabel
 reboot

 The machine booted back up in just a few minutes, what looked like 
 normal reboot time.  And then I ran the same commands as before and 
 got what looks to me like the same output:

 [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt
 -rw-rw-rw-  root root system_u:object_r:file_t:s0  
 /var/www/html/robots.txt
 [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
 system_u:system_r:init_t:s0 root  2530  0.0  0.4  21680  8820 
 ?Ss   16:23   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2558  0.8  0.8  28308 16392 
 ?S16:23   0:03 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2560  0.5  0.5  23248 10236 
 ?S16:23   0:02 /usr/sbin/httpd

 So I'm wondering:
 1) How did you know that the machine needed to be relabeled, was it 
 something in the output of the commands the first time I ran them? and 
 in that case,
 2) Why didn't it change after I created /.autorelabel and rebooted?
 (I can confirm the file /.autorelabel is no longer present, so it must 
 have been deleted when the auto-relabel was done, like the doc says.)
 3) If the machine booted back up very quickly, should I be worried 
 that the autorelabel might not have happened?  Any idea if it logs a 
 message somewhere if it fails to start properly?
OK, I know why Daniel and Rilindo were telling me to relabel -- according to
http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions
and other sources, if a file is listed as type file_t, it means the 
system needs to be relabeled.

So I still don't know: after creating /.autorelabel (and verifying that 
it's there), and rebooting the system (and then verifying that the 
/.autorelabel file has been deleted, which is supposed to mean the 
auto-relabel actually happened), why am I still seeing the file type 
listed as file_t?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/5/2012 1:36 PM, Bennett Haselton wrote:
 http://wiki.centos.org/HowTos/SELinux
 says:
 Access is only allowed between similar types, so Apache running as 
 httpd_t can read /var/www/html/index.html of type httpd_sys_content_t.

 however the doc doesn't define what similar types means.  I assumed 
 it just meant beginning with the same prefix.  However that can't be 
 right because on my system with SELinux turned on, httpd runs as type 
 init_t:

 [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
 system_u:system_r:init_t:s0 root  2521  0.1  0.4  21680  8820 
 ?Ss   05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2550  0.0  0.4  23364  8920 
 ?S05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2551  0.1  0.4  22736  8212 
 ?S05:05   0:00 /usr/sbin/httpd

 and the robots.txt file has type file_t:
 [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt
 -rw-rw-rw-  root root system_u:object_r:file_t:s0  
 /var/www/html/robots.txt

 but Apache can of course access that file.  So in Type Enforcement, 
 what determines what process type can access what file type?

OK, notwithstanding the fact that the filesystem on the above machine 
needs to be re-labeled and I don't know why that's failing --

I have another CentOS 5.7 machine where I've enabled SELinux (permissive 
mode) and relabeled the filesystem and it actually worked, so that the 
above commands are now giving the expected outputs:

[root@g6950-21025 ~]# ps awuxZ | grep httpd | head -n 3
system_u:system_r:init_troot  2302  0.0  1.0 253056 10576 
?Ss   00:12   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache4201  0.1  2.0 274804 20968 
?S01:26   0:02 /usr/sbin/httpd
system_u:system_r:init_tapache4392  0.2  1.2 257308 12512 
?S01:39   0:01 /usr/sbin/httpd
[root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt
-rw-rw-rw-  root root system_u:object_r:httpd_sys_content_t 
/var/www/html/robots.txt
[root@g6950-21025 ~]#

So, same question -- the documentation says Access is only allowed 
between similar types, but what does similar mean?  What determines 
that the httpd process, running under the init_t domain, can access 
the robots.txt file, which has type httpd_sys_content_t?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/6/2012 2:24 AM, Philippe Naudin wrote:
 Le ven 06 jan 2012 02:00:27 CET, Bennett Haselton a écrit:

 On 1/5/2012 1:36 PM, Bennett Haselton wrote:
 ...
 OK, notwithstanding the fact that the filesystem on the above machine
 needs to be re-labeled and I don't know why that's failing --

 I have another CentOS 5.7 machine where I've enabled SELinux (permissive
 mode) and relabeled the filesystem and it actually worked, so that the
 above commands are now giving the expected outputs:

 [root@g6950-21025 ~]# ps awuxZ | grep httpd | head -n 3
 system_u:system_r:init_troot  2302  0.0  1.0 253056 10576
 ?Ss   00:12   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache4201  0.1  2.0 274804 20968
 ?S01:26   0:02 /usr/sbin/httpd
 system_u:system_r:init_tapache4392  0.2  1.2 257308 12512
 ?S01:39   0:01 /usr/sbin/httpd
 Apache running as init_t is a call for troubles.
Is it?  OK, any idea what caused that and how to fix it?

I can't find much on Google about it except this page:
http://fedoraproject.org/wiki/SELinux/EnforcePolicy
says The init process then runs /etc/rc.d/rc.sysinit, which is labeled 
initrc_exec_t. The kernel has a rule that says when init_t execs 
initrc_exec_t it transitions to initrc_t. So this continues until the 
httpd executable gets started as httpd_t.  Even though in my case it's 
not happening.

 $ ps awuxZ | grep [a]pache
 system_u:system_r:httpd_t   apache   ...  /usr/sbin/httpd

 [root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt
 -rw-rw-rw-  root root system_u:object_r:httpd_sys_content_t
 /var/www/html/robots.txt
 This is correct.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/6/2012 4:11 AM, Philippe Naudin wrote:
 Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit:

 On 1/6/2012 2:24 AM, Philippe Naudin wrote:
 Apache running as init_t is a call for troubles.
 Is it?  OK, any idea what caused that and how to fix it?
 No, sorry. Your httpd comes from CentOS ?
Yes
 Afaik, you should not have any process running in context init_t except
 init itself. If ps awuxZ | grep [i]nit_t returns more than only init
 and httpd, your problem is likely to be more complicated than a broken
 configuration of apache.

I've got a few...

[root@g6950-21025 ~]# ps auwxZ | grep init_t
system_u:system_r:init_troot 1  0.6  0.0  10368   712 
?Ss   04:17   0:00 init [3]

system_u:system_r:init_troot   537  0.2  0.1  13728  1976 
?Ss  04:17   0:00 /sbin/udevd -d
system_u:system_r:init_troot  1684  0.0  0.0  38880   456 
?Ssl  04:18   0:00 brcm_iscsiuio
system_u:system_r:init_troot  1690  0.0  0.0  12152   476 
?Ss   04:18   0:00 iscsid
system_u:system_r:init_troot  1691  0.0  0.4  12648  4460 
?SLs 04:18   0:00 iscsid
system_u:system_r:init_tdbus  2081  0.0  0.1  31520  1144 
?Ssl  04:18   0:00 dbus-daemon --system
system_u:system_r:init_troot  2215  0.0  0.1  52372  1492 
?Ssl  04:18   0:00 automount
system_u:system_r:init_troot  2254  0.0  0.1  62656  1212 
?Ss   04:18   0:00 /usr/sbin/sshd
system_u:system_r:init_tntp   2273  0.0  0.4  23412  5044 
?SLs  04:18   0:00 ntpd -u ntp:ntp -p /var
/run/ntpd.pid -g
system_u:system_r:init_troot  2287  0.1  1.0 253312 10580 
?Ss   04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2315  0.3  1.3 259488 13376 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2316  0.0  1.0 257436 11124 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2317  0.1  1.1 257436 11288 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2318  0.1  1.1 257436 11292 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2319  0.0  1.0 256720 10504 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2320  0.1  1.0 257436 10752 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2321  0.0  1.1 257436 11272 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_tapache2322  0.1  1.1 257436 11356 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_troot  2386  0.0  0.0   3812   492 
tty1 Ss+  04:18   0:00 /sbin/mingetty tty1
system_u:system_r:init_troot  2387  0.0  0.0   3812   488 
tty2 Ss+  04:18   0:00 /sbin/mingetty tty2
system_u:system_r:init_troot  2390  0.0  0.0   3812   488 
tty3 Ss+  04:18   0:00 /sbin/mingetty tty3
system_u:system_r:init_troot  2392  0.0  0.0   3812   492 
tty4 Ss+  04:18   0:00 /sbin/mingetty tty4
system_u:system_r:init_troot  2394  0.0  0.0   3812   488 
tty5 Ss+  04:18   0:00 /sbin/mingetty tty5
system_u:system_r:init_troot  2397  0.0  0.0   3812   488 
tty6 Ss+  04:18   0:00 /sbin/mingetty tty6
system_u:system_r:init_tapache2405  0.1  1.0 256412 11008 
?S04:18   0:00 /usr/sbin/httpd
system_u:system_r:init_troot  2406  0.3  0.3  90156  3456 
?Ss   04:18   0:00 sshd: root@pts/0
root:system_r:initrc_t:SystemLow-SystemHigh root 2458 0.0  0.0 61176 768 
pts/0 S+   04:18   0:00 grep init_t



I also found at least one file (the audit.log file) which has file type 
file_t, even though I thought the filesystem had been re-labeled 
successfully because /var/www/html/robots.txt had the correct type:

[root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt
-rw-rw-rw-  root root system_u:object_r:httpd_sys_content_t 
/var/www/html/robots.txt
[root@g6950-21025 ~]# ls -lZ /var/log/audit/audit.log
-rw---  root root system_u:object_r:file_t 
/var/log/audit/audit.log


Any idea (1) what could be causing that and (2) whether it could be 
related to the problem with all those init_t processes?


 If only httpd is concerned, check ls -Z /usr/sbin/httpd :
 -rwxr-xr-x  root root system_u:object_r:httpd_exec_t   /usr/sbin/httpd
 and try eventually yum reinstall httpd ...


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/6/2012 5:55 AM, RILINDO FOSTER wrote:
 On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote:

 Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit:

 On 1/6/2012 4:11 AM, Philippe Naudin wrote:
 Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit:

 On 1/6/2012 2:24 AM, Philippe Naudin wrote:
 Apache running as init_t is a call for troubles.
 Is it?  OK, any idea what caused that and how to fix it?
 No, sorry. Your httpd comes from CentOS ?
 Yes
 Afaik, you should not have any process running in context init_t except
 init itself. If ps awuxZ | grep [i]nit_t returns more than only init
 and httpd, your problem is likely to be more complicated than a broken
 configuration of apache.
 I've got a few...

 [root@g6950-21025 ~]# ps auwxZ | grep init_t
 system_u:system_r:init_troot 1  0.6  0.0  10368   712
 ?Ss   04:17   0:00 init [3]

 system_u:system_r:init_troot   537  0.2  0.1  13728  1976
 ?Ss  04:17   0:00 /sbin/udevd -d
 system_u:system_r:init_troot  1684  0.0  0.0  38880   456
 ?Ssl  04:18   0:00 brcm_iscsiuio
 system_u:system_r:init_troot  1690  0.0  0.0  12152   476
 ?Ss   04:18   0:00 iscsid
 system_u:system_r:init_troot  1691  0.0  0.4  12648  4460
 ?SLs 04:18   0:00 iscsid
 system_u:system_r:init_tdbus  2081  0.0  0.1  31520  1144
 ?Ssl  04:18   0:00 dbus-daemon --system
 system_u:system_r:init_troot  2215  0.0  0.1  52372  1492
 ?Ssl  04:18   0:00 automount
 system_u:system_r:init_troot  2254  0.0  0.1  62656  1212
 ?Ss   04:18   0:00 /usr/sbin/sshd
 system_u:system_r:init_tntp   2273  0.0  0.4  23412  5044
 ?SLs  04:18   0:00 ntpd -u ntp:ntp -p /var
 /run/ntpd.pid -g
 system_u:system_r:init_troot  2287  0.1  1.0 253312 10580
 ?Ss   04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2315  0.3  1.3 259488 13376
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2316  0.0  1.0 257436 11124
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2317  0.1  1.1 257436 11288
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2318  0.1  1.1 257436 11292
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2319  0.0  1.0 256720 10504
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2320  0.1  1.0 257436 10752
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2321  0.0  1.1 257436 11272
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_tapache2322  0.1  1.1 257436 11356
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_troot  2386  0.0  0.0   3812   492
 tty1 Ss+  04:18   0:00 /sbin/mingetty tty1
 system_u:system_r:init_troot  2387  0.0  0.0   3812   488
 tty2 Ss+  04:18   0:00 /sbin/mingetty tty2
 system_u:system_r:init_troot  2390  0.0  0.0   3812   488
 tty3 Ss+  04:18   0:00 /sbin/mingetty tty3
 system_u:system_r:init_troot  2392  0.0  0.0   3812   492
 tty4 Ss+  04:18   0:00 /sbin/mingetty tty4
 system_u:system_r:init_troot  2394  0.0  0.0   3812   488
 tty5 Ss+  04:18   0:00 /sbin/mingetty tty5
 system_u:system_r:init_troot  2397  0.0  0.0   3812   488
 tty6 Ss+  04:18   0:00 /sbin/mingetty tty6
 system_u:system_r:init_tapache2405  0.1  1.0 256412 11008
 ?S04:18   0:00 /usr/sbin/httpd
 system_u:system_r:init_troot  2406  0.3  0.3  90156  3456
 ?Ss   04:18   0:00 sshd: root@pts/0
 root:system_r:initrc_t:SystemLow-SystemHigh root 2458 0.0  0.0 61176 768
 pts/0 S+   04:18   0:00 grep init_t



 I also found at least one file (the audit.log file) which has file type
 file_t, even though I thought the filesystem had been re-labeled
 successfully because /var/www/html/robots.txt had the correct type:

 [root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt
 -rw-rw-rw-  root root system_u:object_r:httpd_sys_content_t
 /var/www/html/robots.txt
 [root@g6950-21025 ~]# ls -lZ /var/log/audit/audit.log
 -rw---  root root system_u:object_r:file_t
 /var/log/audit/audit.log


 Any idea (1) what could be causing that and (2) whether it could be
 related to the problem with all those init_t processes?
 It's easy : your init process is broken, all these daemons but init
 are mis-labeled, so all the files they create (such as log files) are
 mis-labeled.

 And if the next question is how to fix it ?, the answer is easy
 too : I don't have any clue...


 Assuming that httpd came from CentOS, it should be appropriate relabeled. If 
 not, using the semanage -f context would fix it.
Are you talking about changing the security context on the 
/usr/sbin/httpd file itself?  What should it be set

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/6/2012 5:58 AM, RILINDO FOSTER wrote:
 On Jan 5, 2012, at 7:37 PM, Bennett Haselton wrote:

 On 1/5/2012 3:14 PM, RILINDO FOSTER wrote:
 On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/05/2012 04:36 PM, Bennett Haselton wrote:
 http://wiki.centos.org/HowTos/SELinux says: Access is only allowed
 between similar types, so Apache running as httpd_t can read
 /var/www/html/index.html of type httpd_sys_content_t.

 however the doc doesn't define what similar types means.  I
 assumed it just meant beginning with the same prefix.  However
 that can't be right because on my system with SELinux turned on,
 httpd runs as type init_t:

 [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
 system_u:system_r:init_t:s0 root  2521  0.1  0.4  21680
 8820 ?Ss   05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2550  0.0  0.4  23364
 8920 ?S05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2551  0.1  0.4  22736
 8212 ?S05:05   0:00 /usr/sbin/httpd

 and the robots.txt file has type file_t: [root@peacefire04 - /root
 # ls -lZ /var/www/html/robots.txt -rw-rw-rw-  root root
 system_u:object_r:file_t:s0 /var/www/html/robots.txt

 but Apache can of course access that file.  So in Type Enforcement,
 what determines what process type can access what file type?

 Bennett ___ CentOS
 mailing list CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 Your machine needs to be relabeled.

 touch /.autorelabel
 reboot
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5
 lFkAnjLTi3zphekGomv04ZyMu0sOuopg
 =cIvM
 -END PGP SIGNATURE-
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 WARNING: If you have never enabled SELinux for long time, the boot is going 
 to take a while as the system relabels the whole machine. Do not do this 
 unless you can plan for an extend downtime.

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 I did do
 touch /.autorelabel
 reboot

 The machine booted back up in just a few minutes, what looked like
 normal reboot time.  And then I ran the same commands as before and got
 what looks to me like the same output:

 [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt
 -rw-rw-rw-  root root system_u:object_r:file_t:s0
 /var/www/html/robots.txt
 [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
 system_u:system_r:init_t:s0 root  2530  0.0  0.4  21680  8820
 ?Ss   16:23   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2558  0.8  0.8  28308 16392
 ?S16:23   0:03 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2560  0.5  0.5  23248 10236
 ?S16:23   0:02 /usr/sbin/httpd

 So I'm wondering:
 1) How did you know that the machine needed to be relabeled, was it
 something in the output of the commands the first time I ran them? and
 in that case,
 2) Why didn't it change after I created /.autorelabel and rebooted?
 (I can confirm the file /.autorelabel is no longer present, so it must
 have been deleted when the auto-relabel was done, like the doc says.)
 3) If the machine booted back up very quickly, should I be worried that
 the autorelabel might not have happened?  Any idea if it logs a message
 somewhere if it fails to start properly?
 ___

 That sort of sound like a good thing. I would suggest that you do:

 tail -f /var/log/audit/audit.log | audit2allow

 To see what type of alerts you are getting. Likely you will get a lot, as 
 some of the file contexts may not be labeled correctly.

I did that but it produces descriptions all beginning with

Summary:

SELinux is preventing access to files with the label, file_t.


In other words, it's describing errors that are the result of the 
relabeling failure, but it doesn't appear to say anything about what 
*caused* the relabeling failure (or if it does it's buried in so many 
other errors I don't know how to find it).

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/6/2012 7:13 AM, Daniel J Walsh wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/06/2012 09:57 AM, Bennett Haselton wrote:
 On 1/6/2012 5:55 AM, RILINDO FOSTER wrote:
 On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote:

 Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit:

 On 1/6/2012 4:11 AM, Philippe Naudin wrote:
 Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit:

 On 1/6/2012 2:24 AM, Philippe Naudin wrote:
 Apache running as init_t is a call for troubles.
 Is it?  OK, any idea what caused that and how to fix it?
 No, sorry. Your httpd comes from CentOS ?
 Yes
 Afaik, you should not have any process running in context
 init_t except init itself. If ps awuxZ | grep [i]nit_t
 returns more than only init and httpd, your problem is
 likely to be more complicated than a broken configuration
 of apache.
 I've got a few...

 [root@g6950-21025 ~]# ps auwxZ | grep init_t
 system_u:system_r:init_troot 1  0.6  0.0
 10368   712 ?Ss   04:17   0:00 init [3]

 system_u:system_r:init_troot   537  0.2  0.1
 13728  1976 ?Ss  04:17   0:00 /sbin/udevd -d
 system_u:system_r:init_troot  1684  0.0  0.0
 38880   456 ?Ssl  04:18   0:00 brcm_iscsiuio
 system_u:system_r:init_troot  1690  0.0  0.0
 12152   476 ?Ss   04:18   0:00 iscsid
 system_u:system_r:init_troot  1691  0.0  0.4
 12648  4460 ?SLs 04:18   0:00 iscsid
 system_u:system_r:init_tdbus  2081  0.0  0.1
 31520  1144 ?Ssl  04:18   0:00 dbus-daemon --system
 system_u:system_r:init_troot  2215  0.0  0.1
 52372  1492 ?Ssl  04:18   0:00 automount
 system_u:system_r:init_troot  2254  0.0  0.1
 62656  1212 ?Ss   04:18   0:00 /usr/sbin/sshd
 system_u:system_r:init_tntp   2273  0.0  0.4
 23412  5044 ?SLs  04:18   0:00 ntpd -u ntp:ntp -p
 /var /run/ntpd.pid -g system_u:system_r:init_troot
 2287  0.1  1.0 253312 10580 ?Ss   04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2315  0.3  1.3 259488 13376 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2316  0.0  1.0 257436 11124 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2317  0.1  1.1 257436 11288 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2318  0.1  1.1 257436 11292 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2319  0.0  1.0 256720 10504 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2320  0.1  1.0 257436 10752 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2321  0.0  1.1 257436 11272 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_tapache
 2322  0.1  1.1 257436 11356 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_troot
 2386  0.0  0.0   3812   492 tty1 Ss+  04:18   0:00
 /sbin/mingetty tty1 system_u:system_r:init_troot
 2387  0.0  0.0   3812   488 tty2 Ss+  04:18   0:00
 /sbin/mingetty tty2 system_u:system_r:init_troot
 2390  0.0  0.0   3812   488 tty3 Ss+  04:18   0:00
 /sbin/mingetty tty3 system_u:system_r:init_troot
 2392  0.0  0.0   3812   492 tty4 Ss+  04:18   0:00
 /sbin/mingetty tty4 system_u:system_r:init_troot
 2394  0.0  0.0   3812   488 tty5 Ss+  04:18   0:00
 /sbin/mingetty tty5 system_u:system_r:init_troot
 2397  0.0  0.0   3812   488 tty6 Ss+  04:18   0:00
 /sbin/mingetty tty6 system_u:system_r:init_tapache
 2405  0.1  1.0 256412 11008 ?S04:18   0:00
 /usr/sbin/httpd system_u:system_r:init_troot
 2406  0.3  0.3  90156  3456 ?Ss   04:18   0:00 sshd:
 root@pts/0 root:system_r:initrc_t:SystemLow-SystemHigh root
 2458 0.0  0.0 61176 768 pts/0 S+   04:18   0:00 grep init_t



 I also found at least one file (the audit.log file) which has
 file type file_t, even though I thought the filesystem had
 been re-labeled successfully because /var/www/html/robots.txt
 had the correct type:

 [root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt
 -rw-rw-rw-  root root system_u:object_r:httpd_sys_content_t
 /var/www/html/robots.txt [root@g6950-21025 ~]# ls -lZ
 /var/log/audit/audit.log -rw---  root root
 system_u:object_r:file_t /var/log/audit/audit.log


 Any idea (1) what could be causing that and (2) whether it
 could be related to the problem with all those init_t
 processes?
 It's easy : your init process is broken, all these daemons but
 init are mis-labeled, so all the files they create (such as log
 files) are mis-labeled.

 And if the next question is how to fix it ?, the answer is
 easy too : I don't have any clue...


 Assuming that httpd came from CentOS, it should be appropriate
 relabeled. If not, using the semanage -f context would fix it.
 Are you talking about changing the security

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/6/2012 6:16 PM, RILINDO FOSTER wrote:
 On Jan 6, 2012, at 10:35 AM, Bennett Haselton wrote:

 I tried that and it worked -- the httpd processes are now listed with
 httpd_t as their context, the /var/log/audit/audit.log file is listed
 with auditd_log_t as its type instead if file_t, etc.

 I'm pretty sure this machine was never upgraded to CentOS 5.2, it was
 just imaged with 5.7 when the hosting company set it up, but SELinux
 *was* off until I turned it on.  So probably the doc should say, if the
 system was *installed* with 5.2, then do this (and presumably it's 5.2
 or later, not just 5.2).
 Either that, or the base install was an earlier version of Centos 5.x,  with 
 SELinux turned off then upgraded to the current version.

   - Rilindo

Could be in theory but if the hosting company was provisioning a new 
machine I don't know why they'd set up an earlier version and then 
upgrade, instead of just imaging the latest version at the time.

As for the original question -- when the docs say that access is allowed 
only across similar types, what determines what counts as similar 
types?  How do you know for example that httpd running as type httpd_t 
can access /var/www/html/robots.txt which has type httpd_sys_content_t?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/5/2012 6:53 AM, Johnny Hughes wrote:
 On 01/04/2012 07:47 PM, Bennett Haselton wrote:
 On 1/4/2012 1:59 PM, Lamar Owen wrote:
 [Distilling to the core matter; everything else is peripheral.]

 On Jan 4, 2012, at 2:58 PM, Bennett Haselton wrote:
 To be absolutely clear: Do you, personally, believe there is more than a
 1 in a million chance that the attacker who got into my machine, got it
 by brute-forcing the password?  As opposed to, say, using an underground
 exploit?
 Here's how I see it breaking down:

 1.) Attacker uses apache remote exploit (or other means) to obtain
 your /etc/shadow file (not a remote shell, just GET the file without
 that fact being logged);
 2.) Attacker runs cloud-based (and/or CUDA accelerated) brute-forcer
 on 10,000,000 machines against your /etc/shadow file without your
 knowledge;
 3.) Some time passes;
 4.) Attacker obtains your password using distributed brute forcing of
 the hash in the window of time prior to you resetting it;
 5.) Attacker logs in since you allow password login.  You're pwned by
 a non-login brute-force attack.

 In contrast, with ssh keys and no password logins allowed:

 1.) Attacker obtains /etc/shadow and cracks your password after some
 time;
 2.) Attacker additionally obtains /root/.ssh/*
 3.) Attacker now has your public key.  Good for them; public keys
 don't have to be kept secure since it is vastly more difficult to
 reverse known plaintext, known ciphertext, and the public key into a
 working private key than it is to brute-force the /etc/shadow hash
 (part of the difficulty is getting all three required components to
 successfully reverse your private key; the other part boils down to
 factoring and hash brute-forcing);
 4.) Attacker also has root's public and private keys, if there is a
 pair in root's ~/.ssh, which may or may not help them.  If there's a
 passphrase on the private key, it's quite difficult to obtain that
 from the key;
 5.) Attacker can't leverage either your public key or root's key pair
 (or the machine key; even if they can leverage that to do MitM (which
 they can and likely will) that doesn't help them obtain your private
 key for authentication;
 6.) Attacker still can't get in because you don't allow password
 login, even though attacker has root's password.

 This only requires an apache httpd exploit that allows reading of any
 file; no files have to be modified and no shells have to be acquired
 through any exploits.  Those make it faster, for sure; but even then
 the attacker is going to acquire your /etc/shadow as one of the first
 things they do; the next thing they're going to do is install a
 rootkit with a backdoor password.

 Brute-forcing by hash-cracking, not by attempting to login over ssh,
 is what I'm talking about.
 I acknowledged that the first time I replied to someone's post saying a
 12-char password wasn't secure enough.  I hypothesized an attacker with
 the fastest GPU-driven password cracker in the world (even allowing for
 100-factor improvements in coming years) and it would still take
 centuries to break.  I understand about brute-forcing the hash vs.
 brute-forcing the login, but some others had posted about brute-forcing
 the login specifically and I was commenting on how ridiculous that was.

 This is what I mean when I say 'multilayer metasploit-driven attacks.'

 The weakest link is the security of /etc/shadow on the server for
 password auth (unless you use a different auth method on your server,
 like LDAP or other, but that just adds a layer, making the attacker
 work harder to get that all-import password).  Key based auth is
 superior, since the attacker reading any file on your server cannot
 compromise the security.

 Kerberos is better still.

 Now, the weakest link for key auth is the private key itself.  But
 it's better protected than any password is (if someone can swipe your
 private key off of your workstation you have bigger problems, and they
 will have your /etc/shadow for your workstation, and probably a
 backdoor.).  The passphrase is also better protected than the
 typical MD5 hash password, too.

 It is the consensus of the security community that key-based
 authentication with strong private key passphrases is better than any
 password-only authentication, and that consensus is based on facts
 derived from evidence of actual break-ins.
 Well yes, on average, password-authentication is going to be worse
 because it includes people in the sample who are using passwords like
 Patricia.  Did they compare the break-in rate for systems with 12-char
 passwords vs. systems with keys?

 I have nothing in particular against ssh keys - how could anybody be
 against ssh keys? :)  My point was that when I asked How did
 attackers probably get in, given that the password was a random
 12-character string? people pounced on the fact that I was using a
 password at all, and kept insisting that that had a non-trivial
 likelihood of being the cause (rather than

[CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

http://wiki.centos.org/HowTos/SELinux
says:
Access is only allowed between similar types, so Apache running as 
httpd_t can read /var/www/html/index.html of type httpd_sys_content_t.

however the doc doesn't define what similar types means.  I assumed it 
just meant beginning with the same prefix.  However that can't be 
right because on my system with SELinux turned on, httpd runs as type 
init_t:

[root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
system_u:system_r:init_t:s0 root  2521  0.1  0.4  21680  8820 
?Ss   05:05   0:00 /usr/sbin/httpd
system_u:system_r:init_t:s0 apache2550  0.0  0.4  23364  8920 
?S05:05   0:00 /usr/sbin/httpd
system_u:system_r:init_t:s0 apache2551  0.1  0.4  22736  8212 
?S05:05   0:00 /usr/sbin/httpd

and the robots.txt file has type file_t:
[root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt
-rw-rw-rw-  root root system_u:object_r:file_t:s0  
/var/www/html/robots.txt

but Apache can of course access that file.  So in Type Enforcement, what 
determines what process type can access what file type?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] SELinux and access across 'similar types'

[Bennett Haselton]

On 1/5/2012 3:14 PM, RILINDO FOSTER wrote:
 On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/05/2012 04:36 PM, Bennett Haselton wrote:
 http://wiki.centos.org/HowTos/SELinux says: Access is only allowed
 between similar types, so Apache running as httpd_t can read
 /var/www/html/index.html of type httpd_sys_content_t.

 however the doc doesn't define what similar types means.  I
 assumed it just meant beginning with the same prefix.  However
 that can't be right because on my system with SELinux turned on,
 httpd runs as type init_t:

 [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
 system_u:system_r:init_t:s0 root  2521  0.1  0.4  21680
 8820 ?Ss   05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2550  0.0  0.4  23364
 8920 ?S05:05   0:00 /usr/sbin/httpd
 system_u:system_r:init_t:s0 apache2551  0.1  0.4  22736
 8212 ?S05:05   0:00 /usr/sbin/httpd

 and the robots.txt file has type file_t: [root@peacefire04 - /root
 # ls -lZ /var/www/html/robots.txt -rw-rw-rw-  root root
 system_u:object_r:file_t:s0 /var/www/html/robots.txt

 but Apache can of course access that file.  So in Type Enforcement,
 what determines what process type can access what file type?

 Bennett ___ CentOS
 mailing list CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

 Your machine needs to be relabeled.

 touch /.autorelabel
 reboot
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5
 lFkAnjLTi3zphekGomv04ZyMu0sOuopg
 =cIvM
 -END PGP SIGNATURE-
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 WARNING: If you have never enabled SELinux for long time, the boot is going 
 to take a while as the system relabels the whole machine. Do not do this 
 unless you can plan for an extend downtime.

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
I did do
touch /.autorelabel
reboot

The machine booted back up in just a few minutes, what looked like 
normal reboot time.  And then I ran the same commands as before and got 
what looks to me like the same output:

[root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt
-rw-rw-rw-  root root system_u:object_r:file_t:s0  
/var/www/html/robots.txt
[root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3
system_u:system_r:init_t:s0 root  2530  0.0  0.4  21680  8820 
?Ss   16:23   0:00 /usr/sbin/httpd
system_u:system_r:init_t:s0 apache2558  0.8  0.8  28308 16392 
?S16:23   0:03 /usr/sbin/httpd
system_u:system_r:init_t:s0 apache2560  0.5  0.5  23248 10236 
?S16:23   0:02 /usr/sbin/httpd

So I'm wondering:
1) How did you know that the machine needed to be relabeled, was it 
something in the output of the commands the first time I ran them? and 
in that case,
2) Why didn't it change after I created /.autorelabel and rebooted?
(I can confirm the file /.autorelabel is no longer present, so it must 
have been deleted when the auto-relabel was done, like the doc says.)
3) If the machine booted back up very quickly, should I be worried that 
the autorelabel might not have happened?  Any idea if it logs a message 
somewhere if it fails to start properly?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS-docs] edit proposal to /HowTos/SELinux - how to relabel filesystem

[Bennett Haselton]

Following the steps under Contribute to the Wiki at
http://wiki.centos.org/Contribute#head-42b3d8e26400a106851a61aebe5c2cca54dd79e5

My Wiki name is BennettHaselton.  I wanted to edit this paragraph:

Note: When switching from Disabled to either Permissive or Enforcing 
mode, it is highly recommended that the system be rebooted and the 
filesystem relabeled.

to add:

This can be accomplished with the commands
touch /.autorelabel
reboot
If the file /.autorelabel exists at boot time, SELinux performs a 
filesystem relabel and then deletes /.autorelabel 

Since the current page says to relabel the filesystem but doesn't say 
how to do it; the instructions are easy to find elsewhere on the web, 
but might as well put it on that page too.

Bennett
___
CentOS-docs mailing list
CentOS-docs@centos.org
http://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/4/2012 9:32 AM, Lamar Owen wrote:
 On Tuesday, January 03, 2012 06:12:10 PM Bennett Haselton wrote:
 I'm not sure what their logic is for recommending 80.  But 72 bits
 already means that any attack is so improbable that you'd *literally*
 have to be more worried about the sun going supernova.
 I'd be more worried about Eta Carinae than our sun, as with it's mass it's 
 likely to be a GRB.  The probability of it happening in our lifetime is quite 
 low; yet, if it does happen in our lifetime (actually, if it happened about 
 7,500 years ago!) it will be an extinction event.  So we watch it over time 
 (and we have plates of it going back into the late 1800's).

 Likewise for security; the gaussian curve does have outliers, after all, and 
 while it is highly unlikely for a brute-force attack to actually come up with 
 anything against a single server it is still possible, partially due to the 
 number of servers out there coupled with the sheer number of brute-forcers 
 running.  The odds are not 1 out of 4.7x10^21; they're much better than that 
 since there isn't just a single host attempting the attack.  If I have a 
 botnet of 10,000,000 infected PC's available to attack 100,000,000 servers 
 (close to the number), what are the odds of one of those attacks succeeding?  
 (the fact is that it has happened already; see my excerpted 'in the wild' 
 brute-forcer dictionary below).

(1) Someone already raised the issue of what if you have 10 million 
infected machines instead of just 1; multiple people pointed out that it 
doesn't matter because the limiting factor is the speed at which sshd 
can accept/reject login requests, so it doesn't matter if the attacker 
has 10 million machines or 1.  (2)  If there are 100 million machines 
being attacked, that still doesn't make a brute force attack any more 
likely for my machine.  It's not correct to say that if 10 million of 
those 100 million machines are likely to get compromised, then mine has 
a 10% chance of being compromised, because with a 12-char random 
password the odds are much lower for me than for others in the sample.

If *everyone* used a 12-char random password, then the odds are that 
*none* of the 10 million machines attacking 100 million servers would 
hit on a success, not when there are 10^21 possible passwords to choose 
from.

 The critical thing to remember is that in key auth the authenticating key 
 never leaves the client system,...
 Actually, the top answer at that link appears to say that the server
 sends the nonce to the client, and only the client can successfully
 decrypt it.  (Is that what you meant?)
 That's session setup, not authentication.

The paragraph I'm reading appears to say that the server sends the nonce 
to the client, even for *authentication* (after session setup):
http://security.stackexchange.com/questions/3887/is-using-a-public-key-for-logging-in-to-ssh-any-better-than-saving-a-password
After the channel is functional and secure... the server has the public 
key of the user stored. What happens next is that the server creates a 
random value (nonce), encrypts it with the public key and sends it to 
the user. If the user is who is supposed to be, he can decrypt the 
challenge and send it back to the server.

So that's what I meant... you'd said the client sends the nonce to the 
server whereas the page said the server sends the nonce to the client... 
just wanted to make sure I wasn't missing anything.

 The server has to auth to the client first for session setup, but then client 
 auth is performed.  But either way the actual client authenticating key never 
 traverses the wire and is unsniffable.

 Furthermore, when you're dealing with probabilities that ridiculously
 small, they're overwhelmed by the probability that an attack will be
 found against the actual algorithm (which I think is your point about
 possible weaknesses in the stream cipher).
 This has happened; read some SANS archives.  There have been and are exploits 
 in the wild against SSH and SSL; even caused OpenBSD to have to back down 
 from it's claim of never having a remotely exploitable root attack.

 However, *then* you have to take into account the fact that, similarly,
 the odds of a given machine being compromised by a man-in-the-middle
 attack combined with cryptanalysis of the stream cipher, is *also*
 overwhelmed by the probability of a break-in via an exploit in the
 software it's running.  I mean, do you think I'm incorrect about that?
 What you're missing is that low probability is not a preventer of an actual 
 attack succeeding; people do win the lottery even with the odds stacked 
 against them.

 Of the compromised machines on the Internet, what proportion do you
 think were hacked via MITM-and-advanced-crypto, compared to exploits in
 the services?
 I don't have sufficient data to speculate.  SANS or CERT may have that 
 information.

Well, what would you guess, based on what you think is likely?  If I bet 
you

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/4/2012 1:59 PM, Lamar Owen wrote:
 [Distilling to the core matter; everything else is peripheral.]

 On Jan 4, 2012, at 2:58 PM, Bennett Haselton wrote:
 To be absolutely clear: Do you, personally, believe there is more than a
 1 in a million chance that the attacker who got into my machine, got it
 by brute-forcing the password?  As opposed to, say, using an underground
 exploit?

 Here's how I see it breaking down:

 1.) Attacker uses apache remote exploit (or other means) to obtain 
 your /etc/shadow file (not a remote shell, just GET the file without 
 that fact being logged);
 2.) Attacker runs cloud-based (and/or CUDA accelerated) brute-forcer 
 on 10,000,000 machines against your /etc/shadow file without your 
 knowledge;
 3.) Some time passes;
 4.) Attacker obtains your password using distributed brute forcing of 
 the hash in the window of time prior to you resetting it;
 5.) Attacker logs in since you allow password login.  You're pwned by 
 a non-login brute-force attack.

 In contrast, with ssh keys and no password logins allowed:

 1.) Attacker obtains /etc/shadow and cracks your password after some 
 time;
 2.) Attacker additionally obtains /root/.ssh/*
 3.) Attacker now has your public key.  Good for them; public keys 
 don't have to be kept secure since it is vastly more difficult to 
 reverse known plaintext, known ciphertext, and the public key into a 
 working private key than it is to brute-force the /etc/shadow hash 
 (part of the difficulty is getting all three required components to 
 successfully reverse your private key; the other part boils down to 
 factoring and hash brute-forcing);
 4.) Attacker also has root's public and private keys, if there is a 
 pair in root's ~/.ssh, which may or may not help them.  If there's a 
 passphrase on the private key, it's quite difficult to obtain that 
 from the key;
 5.) Attacker can't leverage either your public key or root's key pair 
 (or the machine key; even if they can leverage that to do MitM (which 
 they can and likely will) that doesn't help them obtain your private 
 key for authentication;
 6.) Attacker still can't get in because you don't allow password 
 login, even though attacker has root's password.

 This only requires an apache httpd exploit that allows reading of any 
 file; no files have to be modified and no shells have to be acquired 
 through any exploits.  Those make it faster, for sure; but even then 
 the attacker is going to acquire your /etc/shadow as one of the first 
 things they do; the next thing they're going to do is install a 
 rootkit with a backdoor password.

 Brute-forcing by hash-cracking, not by attempting to login over ssh, 
 is what I'm talking about.
I acknowledged that the first time I replied to someone's post saying a 
12-char password wasn't secure enough.  I hypothesized an attacker with 
the fastest GPU-driven password cracker in the world (even allowing for 
100-factor improvements in coming years) and it would still take 
centuries to break.  I understand about brute-forcing the hash vs. 
brute-forcing the login, but some others had posted about brute-forcing 
the login specifically and I was commenting on how ridiculous that was.

 This is what I mean when I say 'multilayer metasploit-driven attacks.'

 The weakest link is the security of /etc/shadow on the server for 
 password auth (unless you use a different auth method on your server, 
 like LDAP or other, but that just adds a layer, making the attacker 
 work harder to get that all-import password).  Key based auth is 
 superior, since the attacker reading any file on your server cannot 
 compromise the security.

 Kerberos is better still.

 Now, the weakest link for key auth is the private key itself.  But 
 it's better protected than any password is (if someone can swipe your 
 private key off of your workstation you have bigger problems, and they 
 will have your /etc/shadow for your workstation, and probably a 
 backdoor.).  The passphrase is also better protected than the 
 typical MD5 hash password, too.

 It is the consensus of the security community that key-based 
 authentication with strong private key passphrases is better than any 
 password-only authentication, and that consensus is based on facts 
 derived from evidence of actual break-ins. 
Well yes, on average, password-authentication is going to be worse 
because it includes people in the sample who are using passwords like 
Patricia.  Did they compare the break-in rate for systems with 12-char 
passwords vs. systems with keys?

I have nothing in particular against ssh keys - how could anybody be 
against ssh keys? :)  My point was that when I asked How did 
attackers probably get in, given that the password was a random 
12-character string? people pounced on the fact that I was using a 
password at all, and kept insisting that that had a non-trivial 
likelihood of being the cause (rather than the 
less-than-one-in-a-billion it actually was), even

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/4/2012 3:01 PM, Marko Vojinovic wrote:
 On Wednesday 04 January 2012 11:58:07 Bennett Haselton wrote:
 If *everyone* used a 12-char random password, then the odds are that
 *none* of the 10 million machines attacking 100 million servers would
 hit on a success, not when there are 10^21 possible passwords to choose
 from.
 It is too naive to identify the statement something has very low probability
 with the statement it will not happen.

 There are processes in nature that have 1 / 10^21 (or any other) probability
 of happening, but they are detected to actually happen every couple of seconds
 or so (hint: ask any nuclear physicist).
That's because they are observing quantities of particles on the order 
of 10^21, so the odds of the event occurring are realistic.  (Recall 
Avogadro's number is 6 x 10^23, the number of particles in one mole of a 
substance.)
 In a security-related context, relying on low probability is always a risk
 (regardless of how small), and it should be avoided if feasible. IOW, chances
 of 10^insert any number here  to one are *infinitely* bigger than zero.
 Proof --- divide that number by zero to find out how many times it is bigger.
 ;-)

 You should never rely on any probability count if you have critical security
 concerns. Yes, I also use a strong password rather than ssh key (mostly for
 the same reason you do --- convenience), but I understand the risk of doing
 so, I don't have any valuable data on the machine, and I never claim that any
 password is as effective as a ssh key.
Well as I've said it depends on how literally you mean as effective.  
If your password is strong enough that there's only a 1 in 10^10 chance 
of it being broken by an attacker in the next year, then if an 
alternative method reduces that chance to 1 in 10^20, you could do that, 
but I wouldn't bother.

Again, I would have been perfectly happy to use ssh keys -- it would 
have been less work to switch to ssh keys than to write all the messages 
defending 12-char passwords :)  The reason I wrote all those messages 
about 12-char passwords was not because I wanted to avoid switching to 
ssh keys.  It was because I wanted some alternative suggestions for how 
an attacker could have gotten in, given that the chance of brute-forcing 
the password (even if the attacker had obtained the password hash) was 
so astronomically small!
 Btw, I am also one of the lucky people who managed to get hacked by ssh
 brute-forcing. The password was as random as it can get, but the attacker
 just got lucky

Not sure what you mean by as random as it can get, but -- I can write 
this in my sleep by now -- if you have a 12-character password, with 
10^21 possibilities to search from, the odds of an attacker getting 
lucky and guessing it, are less probable than you being hit by a 
meteorite tomorrow.  I can absolutely guarantee you that either the 
password was shorter and less random, or else the attacker got it some 
other way (possibly your machine got infected with malware that captured 
your password and uploaded it to a botnet).

 (he didn't get root, though, just my user password, so I could
 mitigate the damage). After that I installed fail2ban, but I still don't keep
 anything valuable on that machine...

 However, *then* you have to take into account the fact that,
 similarly,
 the odds of a given machine being compromised by a man-in-the-middle
 attack combined with cryptanalysis of the stream cipher, is *also*
 overwhelmed by the probability of a break-in via an exploit in the
 software it's running.  I mean, do you think I'm incorrect about that?
 Are you basically saying that this is a premature optimization problem? If I
 understand your argument correctly, some attack vectors are much more probable
 than others, so guarding against a low-probability attack vector is
 superfluous, given that there are more probable ones still unguarded. Is that
 what you are saying here?

 If yes, let me stress --- the premature optimization issue is *void* in a
 security-related context. The main guideline is rather the cover all bases
 principle. The fact that something is unlikely to happen does not mean you
 should not guard against it, if you can. You may find the pain/gain ratio too
 high sometimes, and you are welcome to ignore some obvious security holes for
 the sake of convenience if you like, but you cannot argue that low-probability
 holes are safe to ignore *in* *principle*. That is where the cover-all-bases
 always wins over avoiding premature optimization.

It depend on what you mean by low probability.  As I said, if it's 
less likely than being hit with a meteor, I don't care.

 The archives of this list already had the information about SELinux
 contained in this thread.  Not to mention the clear and easily
 accessible documentation from the upstream vendor linked to from the
 CentOS website.
 Well every one of the thousands of features and functions of Linux is
 indexed by Google on the web *somewhere

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 11:04 PM, Les Mikesell wrote:
 On Tue, Jan 3, 2012 at 12:41 AM, Bennett Haseltonbenn...@peacefire.org  
 wrote:
 Standard/non-standard isn't the point. The point is to control what an
 app can do even if some unexpected flaw lets it execute arbitrary
 code.
 What's the scenario where this port restriction would make a
 difference?  Suppose an attacker does find a way to make squid execute
 arbitrary code.  Then if part of their plan is to make squid start
 listening on a second port in addition the one it's already using (3128,
 the default), they could just make it listen on another port like 8080
 which is permitted by SELinux.
 You are thinking the wrong direction.  No one can anticipate every
 possibility that someone might do  to take advantage of
 vulnerabilities.  Instead think in terms of the minimum the
 application should be allowed to do under any circumstance. Then
 you'll also have firewalls blocking every port except where you know
 your own application is listening anyway.

I agree about minimum permissions, but my argument here is that 
permitting squid to listen on any arbitrary port it wants is just as 
minimum, in terms of security implications, as permitting it to 
listen on port 3128.  Either way, once the attacker has connected to 
it, the scenarios are identical from that point on (either the attacker 
knows an exploit to take control of squid, or they don't; either the 
squid process runs with sufficiently high privileges that the exploit 
can be used to do damage, or it can't).

 In other words, when SELinux causes a problem, it can take hours or days
 to find out that SELinux is the cause
 Errr, no - all you have to do is disable SELinux and see if the
 behavior changes.  On your test machine where you should be testing
 changes, this shouldn't be a big risk.
 Well I meant, if you didn't happen to know enough about SELinux to
 realize that it was the cause of many non-standard system behaviors.  If
 you knew about SELinux as one of those things that frequently gets in
 the way, then you'd probably think of it a lot faster :)
 Well, the other security rules for linux/unix are trivial, so SELinux
 should pop to mind immediately for surprising behavior, especially if
 you have changed configurations from the expected defaults.

 One could easily say, Hey, you should just know about SELinux, but the
 problem is that there can be dozens of things on a machine that could
 potentially cause failures (without giving a useful error message), and
 each additional thing that you should just know about, decreases the
 chances that any one person would actually know to check them all, if
 they're not a professional admin.
 OK, the point here is that you have some unknown vulnerability that
 the stock linux security mechanisms aren't handling.   I'm more
 inclined to think it is a software bug rather than brute-forcing a
 password, but that's speculation.  So, which do you think will be more
 difficult - tracking down some unknown bug in millions of lines of
 code with no real evidence, or adding another layer of security that
 is mostly pre-configured in the distro anyway?

Well I'm trying to weigh the costs of using it -- with all of the silent 
failures for operations that have no security implications -- against 
the reduced risks.  If many exploits against httpd, for example, could 
have been prevented by SELinux, that may make it worth it.  (And of 
course the suggestions about how to diagnose problems caused by SELinux 
are helpful.)

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 11:01 PM, John R. Dennison wrote:
 On Mon, Jan 02, 2012 at 10:41:15PM -0800, Bennett Haselton wrote:
 Again, you don't have to take my word for it -- in the first 10 Google
 hits of pages with people posting about the problem I ran into, none of
 the people helping them, thought to suggest SELinux as the cause of the
 problem.  (By contrast, when iptables causes a problem, people usually
 figure out that's what's going on.)
 There's a lot of FUD going around in this thread.  If people would
 bother to spend some time _reading_ _documentation_ on the systems they
 are attempting to admin they might find that subsystems such as selinux
 aren't quite as complex as they make them out to be.

Well for one thing, much of the documentation for Linux tools is 
missing, unclear, or sometimes just wrong.  Here's a message I posted 
two years ago:
http://forums.mysql.com/read.php?11,280886,280886#msg-280886
about how when you first install MySQL, it tells you -- shouting in all 
caps, no less -- to set a password by running a pair of commands, where 
the second command is always guaranteed to fail (for reasons explained 
in the post).  I verified this on every dedicated server I had access 
to.  But the message never got answered, and for all I know MySQL still 
shouts the wrong information at every new user who installs it.

However, completely wrong documentation is actually rare; the problem 
with most documentation is that it's unclear or ambiguous, because it's 
written or judged with the mindset that users should know enough to 
resolve the ambiguities and the errors, and if the user doesn't know 
enough to figure out the errors, it's a failing on the user's part.  Or 
the documentation is extremely long-winded and doesn't contain a short 
version that is good enough for 99% of users' purposes, because it's 
assumed that if users don't want to read the 50-page version, that's 
also a failing on the user's part.

I think most unclear documentation could easily be made better.  I'd be 
happy to volunteer for a project where someone writing documentation 
wanted to check to see if it made sense to people who didn't already 
know what the author was trying to say.  But the authors have to want to 
do that.  The main obstacle is the mindset that problems with 
documentation are presumed to be the user's fault.

(To be fair, this isn't a problem specific to Linux documentation; many 
instructions out there are pretty bad, because it's notoriously 
difficult to judge the quality of instructions in a field in which 
you're an expert, since your brain automatically fixes errors and 
ambiguities if you know what the author was trying to say.  Recipes 
written by cooking experts are pretty bad.)

 Oh, and like all
 other aspects of the internet, google is just as susceptible to indexing
 idiots as it is to indexing pertinent and accurate results.

 selinux is fully integrated into the system auditing facilities and even
 provides multiple tools to aid an administrator in problem isolation
 and remediation.  These tools are, of course, fully documented.

 There is _ample_ documentation on the web, starting with the CentOS
 wiki site, that covers selinux in great detail.  I would urge you and
 anyone else not familiar with the facilities that selinux offers, both
 from an enforcement standpoint and also from a management standpoint, to
 spend some quality time reading up on it.

 Blaming selinux itself for creating what you perceive as a problem
 because you won't make a rudimentary attempt at learning to properly
 manage it is ludicrous.

 Anyone that has an internet facing box that does not take advantage of
 each and every security technology at their disposal should be in a
 different line of work.  And taking advantage of such technologies
 requires one to read associated documentation.

 And while this response seems to single you out I mean to point a
 finger at anyone out there that doesn't bother to take time to learn
 about systems / data that they are responsible for.




   John


 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 12:50 AM, Nataraj wrote:
 On 01/02/2012 10:48 PM, Bennett Haselton wrote:
 True but I travel a lot and sometimes need to connect to the machines
 from subnets that I don't know about in advance.
 You could secure another system somewhere on the internet (could be a
 $20/month virtual host), leave no pointers to your production systems on
 that system, and allow remote logins on your production systems from
 that other host.  It's called a back door.
But assuming the attacker is targeting my production system, suppose 
they find a vulnerability and obtain the ability to run commands as root 
on the system.  Then wouldn't their first action be to remove 
restrictions on where you can log in from?  (Or, they could just 
continue to run root commands using whatever trick they'd discovered?)
 You could also take a look
 at something like fwknop.  That in combination with some type of back
 door for the situation where you don't have your keys available should
 cover any situation where you need to get to your system.  But access
 using the key authentication should be preferred and only use the back
 door for emergencies.
 If I used openvpn to connect, and then connected via ssh over openvpn,
 this seems like essentially security through obscurity :) by just
 replacing the public ssh daemon with a different public daemon (with a
 different connection protocol) which an attacker could try to
 brute-force the same way they could try to brute-force sshd.
 Pretty much all security is based on something that you know/have that
 the attacker doesn't know/have. This is true for computer access, the
 locks on your front door and the safe at the bank.

Yes, but the argument for security over obscurity is that the secret 
should reside in something that cannot be obtained even in trillions of 
trillions of guesses (i.e. a strong password), not in something that 
could be obtained in a few dozen or a few thousand guesses (i.e. finding 
OpenVPN listening on a given port).  The reason being is that if 
something is obtainable in a few thousand guesses, then it will create 
the illusion of being unguessable, but an attacker could still get it.

 What your getting
 from the people on this list is their experience, comments based on what
 they did that worked and what they did that didn't.

Unfortunately it may not be possible to tell that a particular safeguard 
ever actually worked or made a difference.  How could you ever know, 
for example, that an attacker was stopped because you used an ssh key 
instead of a 12-character truly random password?

One way you can know is if you have two barriers one behind the other, 
and attackers get through the first barrier but not the second one, then 
you know the second barrier mattered.  That's why the argument for 
SELinux sounds persuasive, because of identified instances where 
attackers circumvented the first barrier (finding a way to make Apache 
create executables in /tmp/) but were stopped by the second (SELinux 
prevented those executables from being run).

 Check the past 10
 years of cert advisories and count the number of security advisories for
 sshd and then count the number for openvpn.

OK, that's different from the obscurity factor (since the difference in 
exploit frequency, would still be a reason to use openvpn instead of 
sshd, even if the attacker knew that you were using it).  However that 
also has to be weighed against the side effects of using a non-standard 
setup.  I assume, for example, that most security audit tools would look 
at IP addresses that attempted to log in via ssh.  That wouldn't work if 
your gateway is OpenVPN instead of sshd.  (In my experience, everything 
you're doing differently from everyone else, makes it harder to get help 
when things go wrong.)

 However it still seems that this would only matter if the attacker got
 in by brute-forcing the login.  If they obtained the ability to run
 privileged commands any other way, then (1) they could continue to run
 privileged commands that way anyway, or (2) as their first action they
 could just remove all the IP address restrictions on ssh connections at
 which point they could connect normally via ssh from anywhere.
 The more security mechanisms you have in place, the greater is the
 probability that even if they made a partial compromise of your system,
 they might fail when they try to get through to the next level and if
 you have warning systems, such as daily reports or even alerts sent to
 your cell phone, you might be able to stop them first.

For partial compromises that makes sense.

However for total compromises (i.e. if attacker is running root commands 
on your system), then presumably this would only work if your tripwire 
warning system was obscure enough that the attacker didn't know to look 
for it.  Otherwise their first action would be to disable the tripwire 
before it warned you.

 So if this only matters when the attacker is trying to brute-force

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 11:36 AM, Ljubomir Ljubojevic wrote:
 On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote:
 Having been on vacation, I'm coming in very late in this

 Les Mikesell wrote:
 On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org
 wrote:
 snip
 OK but those are *users* who have their own passwords that they have
 chosen, presumably.  User-chosen passwords cannot be assumed to be
 secure against a brute-force attack.  What I'm saying is that if you're
 the only user, by my reasoning you don't need fail2ban if you just use a
 12-character truly random password.
 But you aren't exactly an authority when you are still guessing about
 the cause of your problem, are you?  (And haven't mentioned what your
 logs said about failed attempts leading up to the break in...).
 Further, that's a ridiculous assumption. Without fail2ban, or something
 like it, they'll keep trying. You, instead, Bennett, are presumably
 generating that truly random password[1] and assigning it to all your
 users[2], and not allowing them to change their passwords, and you will be
 changing it occasionally and informing them of the change.[3]

 Right?

   mark

 1. How will you generate truly random? Clicks on a Geiger counter? There
 is no such thing as a random number generator.
 2. Which, being truly random, they will write down somewhere, or store
 it on a key, labelling the file mypassword or some such.
 3. How will you notify them of their new password - in plain text?
 Bennet was/is the only one using those systems, and only as root. No
 additional users existed prior to breach. And he is very persisting in
 placing his own opinion/belief above those he asks for help.
That there are 10^21 possible random 12-character alphanumeric passwords 
-- making it secure against brute-forcing -- is a fact, not an opinion.

To date, *nobody* on this thread has ever responded when I said that 
there are 10^21 possible such passwords and as such I don't think that 
the password can be brute-forced in that way.  Almost every time I said 
this, I added, If you think this is incorrect, why do you think it's 
incorrect?, because I did genuinely want to know.  When people didn't 
reply, I thought maybe they hadn't realized before that I was using 
actually long, actually random passwords, and maybe they no longer 
thought that was insecure after all.

Again: Do you think I'm wrong that if you use a 12-character mixed-case 
alphanumeric password, then switching to sshkeys or using fail2ban will 
not make the system any more secure?  If you think I'm wrong, why?  What 
is the exact scenario that you think those would prevent?

 That is why
 we have such a long long long thread. It came to the point where I am
 starting to believe him being a troll. Not sure yet, but it is getting
 there.

The thread grew so long partly because few people were offering 
suggestions on *preventive* measures (mostly on what to do differently 
next time to diagnose after the fact -- which was fine and useful, but I 
kept trying to steer the discussion back to preventive measures), and 
the two preventive measures that did come up the most, were using ssh 
keys and using fail2ban to stop people brute-forcing the login, and I 
kept explaining why I did not think that would make me any safer the 
next time around.

Note that after over 100 messages had been posted on the subject, 
someone did mention SELinux and the specific scenario (which has come up 
in the real world) in which SELinux can stop a break-in (exploit is 
found where attacker takes control of Apache, Apache writes to /tmp dir 
and tries to execute a program there).

If I had accepted the advice offered at the beginning to use keys 
instead of passwords, the discussion might have never gotten past that.  
It was because I stood my ground that brute-forcing a 12-character 
random password was not logically possible, that the discussion 
eventually turned to something which *might* at least reduce the chance 
of a future break-in.

 I am writing this for your sake, not his. I decided to just watch from
 no on. This thread WAS very informative, I did lear A LOT, but enough is
 enough, and I spent far to much time reading this thread.



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 12:31 PM, Pete Travis wrote:
 On Jan 3, 2012 12:36 PM, Ljubomir Ljubojevicoff...@plnet.rs  wrote:
 On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote:
 Having been on vacation, I'm coming in very late in this

 Les Mikesell wrote:
 On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org
 wrote:
 snip
 OK but those are *users* who have their own passwords that they have
 chosen, presumably.  User-chosen passwords cannot be assumed to be
 secure against a brute-force attack.  What I'm saying is that if
 you're
 the only user, by my reasoning you don't need fail2ban if you just
 use a
 12-character truly random password.
 But you aren't exactly an authority when you are still guessing about
 the cause of your problem, are you?  (And haven't mentioned what your
 logs said about failed attempts leading up to the break in...).
 Further, that's a ridiculous assumption. Without fail2ban, or something
 like it, they'll keep trying. You, instead, Bennett, are presumably
 generating that truly random password[1] and assigning it to all your
 users[2], and not allowing them to change their passwords, and you will
 be
 changing it occasionally and informing them of the change.[3]

 Right?

   mark

 1. How will you generate truly random? Clicks on a Geiger counter?
 There
 is no such thing as a random number generator.
 2. Which, being truly random, they will write down somewhere, or store
 it on a key, labelling the file mypassword or some such.
 3. How will you notify them of their new password - in plain text?
 Bennet was/is the only one using those systems, and only as root. No
 additional users existed prior to breach. And he is very persisting in
 placing his own opinion/belief above those he asks for help. That is why
 we have such a long long long thread. It came to the point where I am
 starting to believe him being a troll. Not sure yet, but it is getting
 there.

 I am writing this for your sake, not his. I decided to just watch from
 no on. This thread WAS very informative, I did lear A LOT, but enough is
 enough, and I spent far to much time reading this thread.


 --

 Ljubomir Ljubojevic
 (Love is in the Air)
 PL Computers
 Serbia, Europe

 Google is the Mother, Google is the Father, and traceroute is your
 trusty Spiderman...
 StarOS, Mikrotik and CentOS/RHEL/Linux consultant
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 I'm subscribed to this list just because of threads like this.  I want to
 thank you all for exposing me to knowledge and discussion that reveals far
 more than manpages or readmes - it helps a lot to know where to start
 reading, and about what.

 I am not a statistician,  but I feel an observation should be made on the
 idea of an 'unguessable password.'  A 12 character string may have 12^42
 possible permutations,

I'm not sure where you got the 12^42 figure from.  My assumption was 
that each character has about 64 = 2^6 possible values, so there are 
2^72  possible passwords, which is on the order of 10^24.

 but you are assuming that the correct guess will be
 the last possible guess.

Actually I was using the fact that the average time to break the 
password would be the time required to check half of the possible 
passwords, not that they won't find it until the last possible one.  
That's still on the order of 10^24.

 Simplistic probability puts the odds of success
 at 50% - either the attacker gets it right, or they don't.

I can't make sense of this statement at all.  Just because there are two 
possible outcomes doesn't mean that each possibility is equally likely 
-- you might as well that either the sun comes up tomorrow, or it 
doesn't, so the odds of success are 50% :)  The only time the 50% 
figure comes up is that the average time to guess a password is the time 
taken to check half of all possible passwords, and hence is 50% of the 
worst-case time to guess a password (which would be the time taken to 
check all of them).

 An intelligent
 brute forcing tool could be making some assumptions about the minimum
 length and complexity of your password, and ruling out the dictionary words
 and strings based on them happens quickly.  The next guess has the same
 rough odds of being correct as the 100563674th guess.

Actually, each time you make a guess and it's wrong, the probability of 
success goes up slightly for your next guess.  Imagine having 10 cups 
with a ball under one of them.  The probability of turning over the 
right cup on the first try is 1/10.  If you're wrong, though, then the 
probability of getting it right on the next cup goes up to 1/9, and so on.

But it's all a moot point if there are 10^24 possible passwords and the 
odds of finding the right one in any conceivable length of time are 
essentially zero.

 Of course, no amount of guessing will succeed on a system that doesn't
 accept passwords.   System security, in terms of 

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 12:32 PM, m.r...@5-cent.us wrote:
 Bennett Haselton wrote:
 mark wrote:
 snip
 1. How will you generate truly random? Clicks on a Geiger counter?
 There is no such thing as a random number generator.
 snip
 That there are 10^21 possible random 12-character alphanumeric passwords
 -- making it secure against brute-forcing -- is a fact, not an opinion.

 To date, *nobody* on this thread has ever responded when I said that
 there are 10^21 possible such passwords and as such I don't think that
 the password can be brute-forced in that way.  Almost every time I said
 Ok, I'll answer, here and now: YOU IGNORED MY QUESTION: HOW WILL YOU
 RANDOMLY GENERATE THE PASSWORDS? All algorithmic ones are pseudo-random.
 If someone has any idea what the o/s is, they can guess which
 pseudo-random generator you're using, and can try different salts.
I generally change them from the values assigned by the hosting company, 
and just bang my fingers around on the keyboard, with the shift key 
randomly on and off for good measure :)  This also removes the 
possibility that an incompetent hosting company will store their own 
copy of the password somewhere that it can be compromised.  Even when 
that possibility is very unlikely, it's still astronomically more likely 
than the attacker guessing the password by brute force.

But even if someone did not do that, don't most Linux distros a good 
crypto-random number generator for generating new passwords, when 
they're picked by the machine and not the user?  You can use salts that 
depend on the low bits of high-precision performance counters, and other 
values that are impossible for an attacker to predict.  If any Linux 
implementation is using anything less than a cryptographically strong 
generator for creating passwords, like I said it's not my problem, but I 
would take that up with the developers.

 Someone
 here posted a link to the Rainbow tables, and precomputed partial lists.
 snip
 Again: Do you think I'm wrong that if you use a 12-character mixed-case
 alphanumeric password, then switching to sshkeys or using fail2ban will
 not make the system any more secure?  If you think I'm wrong, why?  What
 is the exact scenario that you think those would prevent?
 Without fail2ban, or something like it, they'll hit your system thousands
 of times an hour, at least. Sooner or later, they'll get lucky.

OK do you *literally mean that* -- that with 10^21 possible passwords 
that an attacker has to search, I have to worry about the attacker 
getting lucky if they're trying thousands of times per hour?

 But I suppose you'll ignore this, as well.

  mark

 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 2:04 PM, Lamar Owen wrote:
 On Tuesday, January 03, 2012 03:24:34 PM Bennett Haselton wrote:
 That there are 10^21 possible random 12-character alphanumeric passwords
 -- making it secure against brute-forcing -- is a fact, not an opinion.

 To date, *nobody* on this thread has ever responded when I said that
 there are 10^21 possible such passwords and as such I don't think that
 the password can be brute-forced in that way.
 Hmm, methinks you need to rethink the number.  The number of truly random 
 passwords available from a character set with N charaters and of a length L 
 is N^L. (see https://en.wikipedia.org/wiki/Password_strength#Random_passwords 
 )

 If L=12, then:
 For:
 The numerals only: 10^12.
 The Uppercase alphabet only: 26^12 (9.5x10^16)
 Uppers and lowers: 52^12 (3.9x10^20)
 Numerals plus uppers and lowers: 62^12 (3.2x10^21)
 Base64: 64^12 (4.7x10^21)

This is the figure I'm using (because I actually use some chars that 
aren't letters or numbers so I rounded up to 64).  You got on the order 
of 10^21, same as me.

 Full ASCII printables, minus space: 94^12 (4.76x10^23)

 This of course includes repeating characters.  NIST recommends 80-bit 
 entropy-equivalent passwords for secure systems; 12 characters chosen at 
 random from the full 95 ASCII printable characters doesn't quite make that 
 (at a calculated 78 bits or so).
I'm not sure what their logic is for recommending 80.  But 72 bits 
already means that any attack is so improbable that you'd *literally* 
have to be more worried about the sun going supernova.
 Having said all of that, please see and read 
 http://security.stackexchange.com/questions/3887/is-using-a-public-key-for-logging-in-to-ssh-any-better-than-saving-a-password

 The critical thing to remember is that in key auth the authenticating key 
 never leaves the client system, rather an encrypted 'nonce' is sent (the 
 nonce is encrypted by the authenticating key), which only the server, 
 possessing the matching key to the authenticating key, can successfully 
 decrypt.
Actually, the top answer at that link appears to say that the server 
sends the nonce to the client, and only the client can successfully 
decrypt it.  (Is that what you meant?)
 This effectively gives full bit-strength for the whole key; 1024 bits of 
 entropy, if you will, for 1024 bit keys.  This would appear to require a 157 
 character random password chosen from all 95 ASCII printable characters to 
 match, in terms of bit entropy.
Yes, I've acknowledged that whether you think 1024 bits is more secure 
than 72 bits depends on how literally you mean more secure.  If the 
odds of an attack working in the next year are 1 in 10^10, you can 
reduce the odds to 1 in 10^20, which in a strict mathematical sense may 
make you more secure, but -- not really.

Furthermore, when you're dealing with probabilities that ridiculously 
small, they're overwhelmed by the probability that an attack will be 
found against the actual algorithm (which I think is your point about 
possible weaknesses in the stream cipher).

However, *then* you have to take into account the fact that, similarly, 
the odds of a given machine being compromised by a man-in-the-middle 
attack combined with cryptanalysis of the stream cipher, is *also* 
overwhelmed by the probability of a break-in via an exploit in the 
software it's running.  I mean, do you think I'm incorrect about that?  
Of the compromised machines on the Internet, what proportion do you 
think were hacked via MITM-and-advanced-crypto, compared to exploits in 
the services?

It was that calculation I was making when I kept insisting that there 
must be something more probable than brute-forcing the login or 
decrypting the session -- and if I hadn't stood my ground about that, 
the discussion never would have gotten around to SELinux, which, if it 
works in the manner described, may actually help.

 Obviously, the authenticating key's protection is paramount, and the 
 passphrase is but one part of that.  But that key never travels over the wire.

 In stark constrast, in password auth the password has to leave the system and 
 traverse the connection, even if it's over an encrypted channel (it's hashed 
 on the server end and compared to the server's stored hash, plus salt (always 
 did like a little salt with my hash!), not the client, right? After all, 
 the client may not possess the algorithm used to generate the hash, but 
 password auth still works.).  This leaves a password vulnerable to a 'man in 
 the middle' attack if a weakness is found in the negotiated stream cipher 
 used in the channel.

 Even with a full man-in-the-middle 'sniff' going on, the key pair 
 authentication is as strong as the crypto used to generate the key pairs, 
 which can be quite a bit stronger than the stream cipher.  (56 bit DES, for 
 instance, can be directly brute-forced in 'reasonable' amounts of time now).  
 Pfft, if I understand the theory correctly (and I always

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 2:10 PM, Pete Travis wrote:
 Here's the qualifying statement I made, in an attempt to preempt pedantic
 squabbles over my choice of arbitrary figures and oversimplified math:
 I am not a statistician,  but
 Here is a statement intended to startle you into re-examining your position:
 Simplistic probability puts the odds of success
 at 50% - either the attacker gets it right, or they don't.

Oh, did you mean something like, Let's pick any value p as the 
probability of the attacker getting in by brute force in a given hour?  
OK, that's different.  But it's still missing the point that if the odds 
of an event happening in the next year are less than the Earth crashing 
into the Sun, then it's not worth worrying about.

There's a more basic error in your math.  If there are two ways X and Y 
to attack a server, and X has a 1 in 100 chance of succeeding and Y has 
a 1 in 10^10 chance of succeeding, then if you reduce the chances of Y 
succeeding to 1 in 10^20, that's only an order of magnitude change in 
the likelihood of Y, *not* an order of magnitude change in the overall 
chance of a break-in, which changes by a negligible amount.
 Here's the intended take home message:
 The next guess has the same
 rough odds of being correct as the 100563674th guess.
 Yes, you have to worry about a brute force attack succeeding, every hour of
 every day that you give it a window to knock on.

 Here is you nitpicking over figures; acknowledging the opportunity for an
 improvement of several orders of magnitude and disregarding it, stuck in
 your misconceptions; and wholly missing the point.
 Actually, each time you make a guess and it's wrong, the probability of
 success goes up slightly for your next guess.  Imagine having 10 cups
 with a ball under one of them.  The probability of turning over the
 right cup on the first try is 1/10.  If you're wrong, though, then the
 probability of getting it right on the next cup goes up to 1/9, and so on.

 But it's all a moot point if there are 10^24 possible passwords and the
 odds of finding the right one in any conceivable length of time are
 essentially zero.

 Of course, no amount of guessing will succeed on a system that doesn't
 accept passwords.   System security, in terms of probability, seems to
 be
 an 'every little bit helps' sort of endeavour.
 Well it depends on how literally you mean every little bit :)  If the
 chance of a break-in occurring in the next year from a given attack is 1
 in 10^10, you can reduce it to 1 in 10^20, but it's already less likely
 than your data center being hit by a meteorite.  The real problem is
 that it takes away from time that can be used for things that have a
 greater likelihood of reducing the chance of a break-in.  If I had taken
 the advice about ssh keys at the beginning of the thread, I never would
 have gotten to the suggestion about SELinux.

 Bennett
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
 I'm moving on from this - much better men than I have tried and failed here.
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 2:13 PM, Lamar Owen wrote:
 On Sunday, January 01, 2012 06:27:32 PM Bennett Haselton wrote:
 (I have already practically worn out my keyboard explaining the math behind
 why I think a 12-character alphanumeric password is secure enough :) )
 Also see:
 https://lwn.net/Articles/369703/
The focus of this article seems to be on systems with multiple users 
where the admin can't necessarily trust all the users to make smart 
decisions.  I've already said that I can see why in that case it might 
be desirable to require users to use ssh keys instead of passwords, 
since you can't force users to use good passwords.  My point was that if 
you're the only user and you can make yourself use a 12-char password 
with enough entropy, that's good enough.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/3/2012 4:21 PM, Les Mikesell wrote:
 On Tue, Jan 3, 2012 at 5:12 PM, Bennett Haseltonbenn...@peacefire.org  
 wrote:
 The critical thing to remember is that in key auth the authenticating key 
 never leaves the client system, rather an encrypted 'nonce' is sent (the 
 nonce is encrypted by the authenticating key), which only the server, 
 possessing the matching key to the authenticating key, can successfully 
 decrypt.
 Actually, the top answer at that link appears to say that the server
 sends the nonce to the client, and only the client can successfully
 decrypt it.  (Is that what you meant?)
 This effectively gives full bit-strength for the whole key; 1024 bits of 
 entropy, if you will, for 1024 bit keys.  This would appear to require a 
 157 character random password chosen from all 95 ASCII printable characters 
 to match, in terms of bit entropy.
 Yes, I've acknowledged that whether you think 1024 bits is more secure
 than 72 bits depends on how literally you mean more secure.  If the
 odds of an attack working in the next year are 1 in 10^10, you can
 reduce the odds to 1 in 10^20, which in a strict mathematical sense may
 make you more secure, but -- not really.
 You are still speculating about the wrong things, though.  Is your
 password written down?  Has anyone ever been in the same room when you
 typed it?  Could a key logger have been installed anywhere you typed
 it?

Right, but these are all valid concerns if you use keys as well.  If 
someone's in the room when you type in the passphrase for your key, they 
might come back in later and take the key and use the passphrase.  If 
they install malware, they can capture the passphrase and the key as well.

 And for the brute-force side of things, these may be done from
 a large number of sources to a large number of targets.  They may be
 too slow to break any specific target but repeat it enough and you'll
 match something, somewhere.
Well yes but that doesn't make *my* password any less secure if it's 
chosen from a space of 10^21 possible passwords.  The attacker will just 
move on.
 Maybe you were just the lucky one that
 day - and if you used the same password on the other(s) they would be
 easy targets.

 However, *then* you have to take into account the fact that, similarly,
 the odds of a given machine being compromised by a man-in-the-middle
 attack combined with cryptanalysis of the stream cipher, is *also*
 overwhelmed by the probability of a break-in via an exploit in the
 software it's running.  I mean, do you think I'm incorrect about that?
 Of the compromised machines on the Internet, what proportion do you
 think were hacked via MITM-and-advanced-crypto, compared to exploits in
 the services?
 Proportions don't matter.  Unless you have something extremely
 valuable to make this machine a target or someone captured your
 password and connection destination it was probably a random hit of a
 random probe.  It doesn't matter if they are likely to work or not,
 some do.

I either disagree or I'm not sure what you're saying.  What do you mean 
that proportions don't matter?  If attack A is 1,000 times more likely 
to work than attack B, you don't think it's more important to guard 
against attack A?  Wasn't that exactly what you were advising when you 
said to worry more about someone capturing my password with a keylogger, 
than brute-forcing it?

 The problem with such basic stuff is that in any field, if there's no
 way to directly test whether something has the desired effect or not, it
 can become part of accepted common sense even if it's ineffective.
 If you have multiple layers of protection and look at your logs,
 you'll see what people are trying.  And they keep trying it because it
 works...

Well they might be trying it because it works against some other 
systems (in particular, brute-forcing a weak password).  That doesn't 
mean it's any more likely to work on a system with a 12-char random 
password.

 If you aren't looking at your logs there's not much use in
 speculating about what might be happening.


 Case in point: in the *entire history of the Internet*, do you think
 there's been a single attack that worked because squid was allowed to
 listen on a non-standard port, that would have been blocked if squid had
 been forced to listen on a standard port?
 Generalize that question to 'do you think attacks are helped by
 permitting applications to use ports the administrator didn't expect
 them to use' and the answer is clearly yes.  There are certainly rogue
 trojans around that do who-knows-what on other connections while
 pretending to be your normal applications.

Well that seems like it would be trivial for the trojan to circumvent -- 
just listen on the standard port, and if you receive a connection that 
contains the secret handshake, switch that connection over into trojan 
mode, while continuing to serve other users' standard requests on the 
same port.  Wouldn't that work?  In that case it seems like 

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On Mon, Jan 2, 2012 at 12:04 AM, Craig White craigwh...@azapple.com wrote:

 On Sun, 2012-01-01 at 14:23 -0800, Bennett Haselton wrote:
  (Sorry, third time -- last one, promise, just giving it a subject line!)
 
  OK, a second machine hosted at the same hosting company has also
 apparently
  been hacked.  Since 2 of out of 3 machines hosted at that company have
 now
  been hacked, but this hasn't happened to any of the other 37 dedicated
  servers that I've got hosted at other hosting companies (also CentOS,
 same
  version or almost), this makes me wonder if there's a security breach at
  this company, like if they store customers' passwords in a place that's
  been hacked.  (Of course it could also be that whatever attacker found an
  exploit, was just scanning that company's address space for hackable
  machines, and didn't happen to scan the address space of the other
 hosting
  companies.)
 
  So, following people's suggestions, the machine is disconnected and
 hooked
  up to a KVM so I can still examine the files.  I've found this file:
  -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
  which appears to be a copy of this exploit script:
  http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
  Note the last-mod date of October 21.
 
  No other files on the system were last modified on October 21st.  However
  there was a security advisory dated October 20th which affected httpd:
 
 http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update
  https://rhn.redhat.com/errata/RHSA-2011-1392.html
 
  and a large number of files on the machine, including lots of files in */
  usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* ,
  have a last-mod date of October 20th.  So I assume that these are files
  which were updated automatically by yum as a result of the patch that
 goes
  with this advisory -- does that sound right?
 
  So a couple of questions that I could use some help with:
 
  1) The last patch affecting httpd was released on October 20th, and the
  earliest evidence I can find of the machine being hacked is a file dated
  October 21st.  This could be just a coincidence, but could it also
 suggest
  that the patch on October 20th introduced a new exploit, which the
 attacker
  then used to get in on October 21st?
  (Another possibility: I think that when yum installs updates, it
  doesn't actually restart httpd.  So maybe even after the patch was
  installed, my old httpd instance kept running and was still vulnerable?
 As
  for why it got hacked the very next day, maybe the attacker looked at the
  newly released patch and reverse-engineered it to figure out where the
  vulnerabilities were, that the patch fixed?)
 
  2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5
  weeks by default, it looks like any log entries related to how the
 attacker
  would have gotten in on or before October 21st, are gone.  (The secure*
  logs do show multiple successful logins as root within the last 4
 weeks,
  mostly from IP addresses in Asia, but that's to be expected once the
  machine was compromised -- it doesn't help track down how they originally
  got in.)  Anywhere else that the logs would contain useful data?
 
 the particular issue which was patched by this httpd (apache) update was
 to fix a problem with reverse proxy so the first question is did this
 server actually have a reverse proxy configured?



I'm not exactly sure how to tell but httpd.conf contains the lines
LoadModule proxy_module modules/mod_proxy.so
LoadModule cache_module modules/mod_cache.so
so I think that means the answer is yes.




My next thought is that since this particular hacker managed to get
 access to more than one of your machines, is it possible that there is a
 mechanism (ie a pre-shared public key) that would allow them access to
 the second server from the first server they managed to crack? The point
 being that this computer may not have been the one that they originally
 cracked and there may not be evidence of cracking on this computer.


 OK, no I don't have pre-shared keys or any other link between them.




 The script you identified would seem to be a script for attacking other
 systems and by the time it landed on your system, it was already broken
 into.



Yes.  That's what I've been saying to some apparently confused people who
thought that the script was used to break into our server :)


 There are some tools to identify a hackers access though they are often
 obscured by the hacker...

 last # reads /var/log/wtmp and provides a list of users, login date/time
 login duration, etc. Read the man page for last to get other options on
 its usage including the '-f' option to read older wtmp log files if
 needed.


Tried that -- looks like this has been obscured by the hacker as you
said, since the output says wtmp begins Sun Jan  1 03:03:28 2012.






lastb # reads /var

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On Sun, Jan 1, 2012 at 6:04 PM, Ljubomir Ljubojevic off...@plnet.rs wrote:

 On 01/02/2012 02:50 AM, Bennett Haselton wrote:
  I'm not sure what you mean by an exploit from a web board which is
  apparently designed to pull outside traffic.  Like Ljubomir said, it
 looks
  like a script that is used from machine X to DOS attack machine Y, if
  machine Y has the VBulletin bulletin board software installed on it.  Is
  that what you meant?:)
 
  But anyway, since the file was located at /home/file.pl (and since
 attacker
  had console access), presumably it wasn't being invoked by the web
 server,
  only from the command line.  So how would it have made any difference if
  httpd was running in its own context, if that script was not being
 invoked
  by httpd?

 Nobody of us really knows how they got in. All you will get from this
 mailing list will be speculations, apart from useful instructions how to
 gather as much info as possible.


Speculation is fine, I'm interested in any method that the attacker *could*
have used to get in to the server if it's *logically possible* that the
attack could have had a non-trivial chance of working.  (If they could have
gotten in by method A, and they could have gotten in by method B, then
regardless of which they DID use, I should still try to fix both A and B.)

But that still excludes things like they got in because you used a
password instead of an ssh key, as I have said many times why a
12-character random alphanumeric password (with 10^24 possible values) is
secure enough even with the most pessimistic assumptions about botnets and
GPUs.



 So there are many possible ways they
 got in including brute force.


Knowing that it was a 12-character random alphanumeric password, do you
still think it could have been done by brute force?




As I understood you, you do not use
 neither fail2ban, denyhosts or/and logwatch, and you haven't checked
 those two servers very much in recent months.

 What Rilindo is saying is that SELinux might detect exploits while their
 trying to break processes from their routine (allowed by SELinux), and
 all of this (if it happened via exploits) might have been prevented by
 SELinux. You really do have lot of gaps in your security.


A couple of people have pointed out gaps in what I was doing for
*detection and analysis* after the fact (don't wipe a machine after it's
hacked, have logs going back further than 4 weeks, have the logs backed up
off-site, etc.), and that's useful.  But as far as I can tell nobody has
really pointed out any gap in what I'm doing on the *prevention* side.

To focus on one exact question: What is a *preventive* measure that you
think I am not doing, that you think would reduce the chance of a break-in,
in some specific scenario?

Take fail2ban and denyhosts, which block connections from IPs that make too
many invalid ssh logins.  In the scenario where the attacker is trying to
brute-force the login, then if your ssh login password is already
un-bruteforceable, then blocking connections from IPs that are making too
many invalid attempts, will not reduce the chance of an attacker
brute-force (which is already essentially zero).

Do you think I'm incorrect that fail2ban and/or denyhosts (and switching
from passwords to ssh keys) do not reduce the chance of a breakin, if your
ssh password is a truly random mixed-case-alphanumeric 12-character
string?  If you think this is incorrect, why?




 If I were you,
 I would use all advice's given to you here and secure the rest of your
 servers (SELinux, fail2ban/denyhosts, logwatch, rsyslog, etc..)


I tried SELinux but it broke so much needed functionality on the server
that it was not an option.  There are many, many issues where all the forum
discussions about how to solve the problem, just end with Just turn off
selinux, and nobody apparently has any other idea how to solve it.  But in
any case, what exactly does it do for httpd security, that isn't already
accomplished by having httpd run as the unprivileged apache user?  You
said SELinux could prevent an exploit from breaking a process from its
routine.  But even without SELinux, an attacker who found an exploit that
could take control of httpd and make it try any action he wanted, still
wouldn't be able to actually do anything while running as apache, would
they?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] 'last' command doesn't include ssh connections made by this perl script?

[Bennett Haselton]

My home machine has IP 50.54.225.130.  I have (for the purposes of this
experiment) one remote machine at www.peacefire.org (69.72.177.140) and
another at www.junkwhale.com.

When I'm logged in to peacefire, I run this perl script to open an ssh
connection to junkwhale and run a command:

my $hostname=www.junkwhale.com;
my $server_password = [redacted!];
use Net::SFTP;
use Net::SSH::Perl;
my $ssh = Net::SSH::Perl-new($hostname);
$ssh-login(root, $server_password);
my($stdout, $stderr, $exit) = $ssh-cmd(pwd);
print Stdout: $stdout\n;
print Stderr: $stderr\n;

If I then log in by ssh to junkwhale from my home computer and run
grep 'Accepted password' /var/log/secure
the last two lines are:
Jan  2 13:23:17 e2180-20059 sshd[12635]: Accepted password for root from
69.72.177.140 port 1023 ssh2
Jan  2 13:23:28 e2180-20059 sshd[12684]: Accepted password for root from
50.54.225.130 port 52484 ssh2

which is correct -- the first line is from the perl script connecting from
Peacefire (69.72.177.140) and the second line is for the connection I just
opened from my home computer.

If, however, I run the last command, the first two lines are just:
root pts/050-54-225-130.ev Mon Jan  2 13:23   still logged in
root pts/050-54-225-130.ev Mon Jan  2 01:52 - 01:52  (00:00)

In other words, the last command doesn't list the connection opened up by
the Perl script.  It only lists the times that I've connected by opening a
connection manually with my SSH client.  Presumably that means the
connection with the perl script is not being logged in /var/log/wtmp ,
although the contents of the file are binary so I couldn't make much sense
of them directly with a screen dump.

This makes me wonder two things:
1) What is the difference, from the server's point of view, between the
connection opened by the script and the one opened by my ssh client; and
2) More seriously, whatever it is that's different about the connection
opened by the perl script, isn't it a bug that that connection is not
recorded in wtmp?  If admins frequently use the last command to determine
who has logged into the server, couldn't an attacker do this to avoid
detection?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 9:18 AM, Les Mikesell wrote:
 On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haseltonbenn...@peacefire.org  
 wrote:
 I tried SELinux but it broke so much needed functionality on the server
 that it was not an option.
 Pretty much all of the stock programs work with SELinux, so this by
 itself implies that you are running 3rd party or local apps that have
 write access in non-standard places.  Which is a good start at what
 you need to break in.   What apps are those (i.e. the ones that
 SELinux would have broken) and if they are open source, have those
 projects updated the app or the underlying language(s)/libraries since
 you have?

So here's a perfect example.  I installed squid on one machine and 
changed it to listen to a non-standard port instead of 3128.  It turns 
out that SELinux blocks this.  (Which I still don't see the reasoning 
behind.  Why would it be any less secure to run a service on a 
non-standard port?  A lot of sources say it's *more* secure to run 
services on a non-standard port if you don't want people poking around!  
In general I don't think it's any more secure to run a service on a 
non-standard port -- all it buys you is time, as it's trivial for an 
attacker to scan all your ports, especially with a botnet -- but even if 
it's not more secure, it certainly shouldn't be *less* secure.)

But here's the real problem.  Since I didn't know it was caused by 
SELinux, all the cache.log file said was:

2012/01/02 17:40:40| commBind: Cannot bind socket FD 13 to *:[portnum 
redacted]: (13) Permission denied

Nothing indicating why.  Even worse, if you Google
+squid +cannot bind socket +permission denied
*none* of the first ten pages that come up, mention SELinux as a 
possible source of the problem.  (One FAQ mentions SELinux but only as 
the source of a different problem.)  All they do is recommend other 
workarounds, each of which takes time to test out, and may have other 
side-effects.

In other words, when SELinux causes a problem, it can take hours or days 
to find out that SELinux is the cause -- and even then you're not done, 
because you have to figure out a workaround if you want to fix the 
problem while keeping SELinux turned on.

-Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 9:18 AM, Les Mikesell wrote:
 There have been many, many vulnerabilities that permit local user
 privilege escalation to root (in the kernel, glibc, suid programs,
 etc.) and there are probably many we still don't know about.  They
 often require writing to the filesystem. For example, one fixed around
 5.4 just required the ability to make a symlink somewhere.   The
 published exploit script (which I've seen in the wild) tries to use
 /tmp.  If the httpd process can't write in /tmp, it would fail.


So are you saying that SELinux is supposed to prevent httpd from writing 
to /tmp ?

Because I just tested that and SELinux didn't appear to stop it.  I set 
selinux to enforcing, rebooted just to make sure, and put this perl 
script on my webserver:

#!/usr/bin/perl
use IO::File;
use strict;
my $fh = IO::File-new( /tmp/foo.txt);
close($fh);
print Content-type: text/html\n\nDone.\n;

then invoked it from the web, and this file was created:
[root@g6950-21025 ~]# ls -l /tmp/foo.txt
-rw-r--r-- 1 apache apache 0 Jan  2 16:47 /tmp/foo.txt

[root@g6950-21025 ~]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#   enforcing - SELinux security policy is enforced.
#   permissive - SELinux prints warnings instead of enforcing.
#   disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
#   targeted - Only targeted network daemons are protected.
#   strict - Full SELinux protection.
SELINUXTYPE=targeted


So it looks like SELinux in this case does not prevent httpd from 
writing to /tmp , in which case it would not have prevented the exploit 
you're referring to.  Or am I missing something?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 8:11 PM, RILINDO FOSTER wrote:
 On Jan 2, 2012, at 9:30 PM, Bennett Haselton wrote:

 On 1/2/2012 9:18 AM, Les Mikesell wrote:
 On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haseltonbenn...@peacefire.org   
 wrote:
 I tried SELinux but it broke so much needed functionality on the server
 that it was not an option.
 Pretty much all of the stock programs work with SELinux, so this by
 itself implies that you are running 3rd party or local apps that have
 write access in non-standard places.  Which is a good start at what
 you need to break in.   What apps are those (i.e. the ones that
 SELinux would have broken) and if they are open source, have those
 projects updated the app or the underlying language(s)/libraries since
 you have?
 So here's a perfect example.  I installed squid on one machine and
 changed it to listen to a non-standard port instead of 3128.  It turns
 out that SELinux blocks this.  (Which I still don't see the reasoning
 behind.  Why would it be any less secure to run a service on a
 non-standard port?  A lot of sources say it's *more* secure to run
 services on a non-standard port if you don't want people poking around!
 In general I don't think it's any more secure to run a service on a
 non-standard port -- all it buys you is time, as it's trivial for an
 attacker to scan all your ports, especially with a botnet -- but even if
 it's not more secure, it certainly shouldn't be *less* secure.)

 But here's the real problem.  Since I didn't know it was caused by
 SELinux, all the cache.log file said was:

 2012/01/02 17:40:40| commBind: Cannot bind socket FD 13 to *:[portnum
 redacted]: (13) Permission denied

 Nothing indicating why.  Even worse, if you Google
 +squid +cannot bind socket +permission denied
 *none* of the first ten pages that come up, mention SELinux as a
 possible source of the problem.  (One FAQ mentions SELinux but only as
 the source of a different problem.)  All they do is recommend other
 workarounds, each of which takes time to test out, and may have other
 side-effects.

 In other words, when SELinux causes a problem, it can take hours or days
 to find out that SELinux is the cause -- and even then you're not done,
 because you have to figure out a workaround if you want to fix the
 problem while keeping SELinux turned on.

 How is it SELinux's problem? Its like running iptables with the default http 
 ports open and then blaming iptables when you change Apache to a non-standard 
 port.
Well for one thing, if you knew iptables was running and you knew what 
it was, you might suspect that it's the cause of the problem, since 
that's the kind of thing iptables is supposed to block.  On the other 
hand, if you knew that SELinux is a security enforcement system, it's 
much less likely to come to mind as the reason why squid can't run on a 
different port, since this achieves nothing for the security of your system.

Don't take my word for it, you can google for people asking about such 
problems.  If someone reports a problem with port blockage that is 
caused by iptables, at least some users will usually suggest iptables as 
the issue.  On the other hand, when I googled for my error which was 
caused by SELinux, nobody in the first ten pages of suggestions knew 
that SELinux could cause this.

So I stand by the statement that SELinux is more likely to cause 
problems that are hard to figure out for people who aren't professional 
admins.

And then there's the fact that solving a problem caused by iptables is 
usually trivial, while every problem caused by SELinux has a different 
solution.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 7:48 PM, Les Mikesell wrote:
 On Mon, Jan 2, 2012 at 8:30 PM, Bennett Haseltonbenn...@peacefire.org  
 wrote:

What apps are those (i.e. the ones that
 SELinux would have broken) and if they are open source, have those
 projects updated the app or the underlying language(s)/libraries since
 you have?
 So here's a perfect example.  I installed squid on one machine and
 changed it to listen to a non-standard port instead of 3128.  It turns
 out that SELinux blocks this.  (Which I still don't see the reasoning
 behind.  Why would it be any less secure to run a service on a
 non-standard port?
 Standard/non-standard isn't the point. The point is to control what an
 app can do even if some unexpected flaw lets it execute arbitrary
 code.
What's the scenario where this port restriction would make a 
difference?  Suppose an attacker does find a way to make squid execute 
arbitrary code.  Then if part of their plan is to make squid start 
listening on a second port in addition the one it's already using (3128, 
the default), they could just make it listen on another port like 8080 
which is permitted by SELinux.
 But here's the real problem.  Since I didn't know it was caused by
 SELinux, all the cache.log file said was:
 Things blocked by SELinux show up in audit.log.  I agree that the
 SELinux implementation is confusing, but it does give more control
 over what apps are allowed to do.

 In other words, when SELinux causes a problem, it can take hours or days
 to find out that SELinux is the cause
 Errr, no - all you have to do is disable SELinux and see if the
 behavior changes.  On your test machine where you should be testing
 changes, this shouldn't be a big risk.
Well I meant, if you didn't happen to know enough about SELinux to 
realize that it was the cause of many non-standard system behaviors.  If 
you knew about SELinux as one of those things that frequently gets in 
the way, then you'd probably think of it a lot faster :)

One could easily say, Hey, you should just know about SELinux, but the 
problem is that there can be dozens of things on a machine that could 
potentially cause failures (without giving a useful error message), and 
each additional thing that you should just know about, decreases the 
chances that any one person would actually know to check them all, if 
they're not a professional admin.

Again, you don't have to take my word for it -- in the first 10 Google 
hits of pages with people posting about the problem I ran into, none of 
the people helping them, thought to suggest SELinux as the cause of the 
problem.  (By contrast, when iptables causes a problem, people usually 
figure out that's what's going on.)

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 7:29 AM, Johnny Hughes wrote:
 On 01/02/2012 02:04 AM, Craig White wrote:
 On Sun, 2012-01-01 at 14:23 -0800, Bennett Haselton wrote:
 (Sorry, third time -- last one, promise, just giving it a subject line!)

 OK, a second machine hosted at the same hosting company has also apparently
 been hacked.  Since 2 of out of 3 machines hosted at that company have now
 been hacked, but this hasn't happened to any of the other 37 dedicated
 servers that I've got hosted at other hosting companies (also CentOS, same
 version or almost), this makes me wonder if there's a security breach at
 this company, like if they store customers' passwords in a place that's
 been hacked.  (Of course it could also be that whatever attacker found an
 exploit, was just scanning that company's address space for hackable
 machines, and didn't happen to scan the address space of the other hosting
 companies.)

 So, following people's suggestions, the machine is disconnected and hooked
 up to a KVM so I can still examine the files.  I've found this file:
 -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
 which appears to be a copy of this exploit script:
 http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
 Note the last-mod date of October 21.

 No other files on the system were last modified on October 21st.  However
 there was a security advisory dated October 20th which affected httpd:
 http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update
 https://rhn.redhat.com/errata/RHSA-2011-1392.html

 and a large number of files on the machine, including lots of files in */
 usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* ,
 have a last-mod date of October 20th.  So I assume that these are files
 which were updated automatically by yum as a result of the patch that goes
 with this advisory -- does that sound right?

 So a couple of questions that I could use some help with:

 1) The last patch affecting httpd was released on October 20th, and the
 earliest evidence I can find of the machine being hacked is a file dated
 October 21st.  This could be just a coincidence, but could it also suggest
 that the patch on October 20th introduced a new exploit, which the attacker
 then used to get in on October 21st?
  (Another possibility: I think that when yum installs updates, it
 doesn't actually restart httpd.  So maybe even after the patch was
 installed, my old httpd instance kept running and was still vulnerable? As
 for why it got hacked the very next day, maybe the attacker looked at the
 newly released patch and reverse-engineered it to figure out where the
 vulnerabilities were, that the patch fixed?)

 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5
 weeks by default, it looks like any log entries related to how the attacker
 would have gotten in on or before October 21st, are gone.  (The secure*
 logs do show multiple successful logins as root within the last 4 weeks,
 mostly from IP addresses in Asia, but that's to be expected once the
 machine was compromised -- it doesn't help track down how they originally
 got in.)  Anywhere else that the logs would contain useful data?
 
 At this point, I would like to point out that if the machine initially
 had ssh access only from subnets where you would have logged in from
 then the Asian subnets would have been excluded.  (Assuming that the
 original attack came from there)

 You can also set up openvpn on the server and control ports like ssh to
 only be open to you if you are using an openvpn client to connect to the
 machine.

True but I travel a lot and sometimes need to connect to the machines 
from subnets that I don't know about in advance.

If I used openvpn to connect, and then connected via ssh over openvpn, 
this seems like essentially security through obscurity :) by just 
replacing the public ssh daemon with a different public daemon (with a 
different connection protocol) which an attacker could try to 
brute-force the same way they could try to brute-force sshd.

However it still seems that this would only matter if the attacker got 
in by brute-forcing the login.  If they obtained the ability to run 
privileged commands any other way, then (1) they could continue to run 
privileged commands that way anyway, or (2) as their first action they 
could just remove all the IP address restrictions on ssh connections at 
which point they could connect normally via ssh from anywhere.

So if this only matters when the attacker is trying to brute-force the 
login, and I still think that a 12-character random password is 
un-bruteforceable which makes the IP restrictions moot.

If I'm wrong, then why?  What do you think -- if my password is already 
a 12-character random string, do think it adds additional security to 
restrict ssh logins to only subnets that I'm logging in from?  If so, 
then what's a specific scenario where

[CentOS] (no subject)

[Bennett Haselton]

(Tried sending this before but it doesn't look like it went through;
apologies if you're seeing it twice.)

OK, a second machine hosted at the same hosting company has also apparently
been hacked.  Since 2 of out of 3 machines hosted at that company have now
been hacked, but this hasn't happened to any of the other 37 dedicated
servers that I've got hosted at other hosting companies (also CentOS, same
version or almost), this makes me wonder if there's a security breach at
this company, like if they store customers' passwords in a place that's
been hacked.  (Of course it could also be that whatever attacker found an
exploit, was just scanning that company's address space for hackable
machines, and didn't happen to scan the address space of the other hosting
companies.)

So, following people's suggestions, the machine is disconnected and hooked
up to a KVM so I can still examine the files.  I've found this file:
-rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
which appears to be a copy of this exploit script:
http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
Note the last-mod date of October 21.

No other files on the system were last modified on October 21st.  However
there was a security advisory dated October 20th which affected httpd:
http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update
https://rhn.redhat.com/errata/RHSA-2011-1392.html

and a large number of files on the machine, including lots of files in */
usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* ,
have a last-mod date of October 20th.  So I assume that these are files
which were updated automatically by yum as a result of the patch that goes
with this advisory -- does that sound right?

So a couple of questions that I could use some help with:

1) The last patch affecting httpd was released on October 20th, and the
earliest evidence I can find of the machine being hacked is a file dated
October 21st.  This could be just a coincidence, but could it also suggest
that the patch on October 20th introduced a new exploit, which the attacker
then used to get in on October 21st?
(Another possibility: I think that when yum installs updates, it
doesn't actually restart httpd.  So maybe even after the patch was
installed, my old httpd instance kept running and was still vulnerable? As
for why it got hacked the very next day, maybe the attacker looked at the
newly released patch and reverse-engineered it to figure out where the
vulnerabilities were, that the patch fixed?)

2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5
weeks by default, it looks like any log entries related to how the attacker
would have gotten in on or before October 21st, are gone.  (The secure*
logs do show multiple successful logins as root within the last 4 weeks,
mostly from IP addresses in Asia, but that's to be expected once the
machine was compromised -- it doesn't help track down how they originally
got in.)  Anywhere else that the logs would contain useful data?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

(Sorry, third time -- last one, promise, just giving it a subject line!)

OK, a second machine hosted at the same hosting company has also apparently
been hacked.  Since 2 of out of 3 machines hosted at that company have now
been hacked, but this hasn't happened to any of the other 37 dedicated
servers that I've got hosted at other hosting companies (also CentOS, same
version or almost), this makes me wonder if there's a security breach at
this company, like if they store customers' passwords in a place that's
been hacked.  (Of course it could also be that whatever attacker found an
exploit, was just scanning that company's address space for hackable
machines, and didn't happen to scan the address space of the other hosting
companies.)

So, following people's suggestions, the machine is disconnected and hooked
up to a KVM so I can still examine the files.  I've found this file:
-rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
which appears to be a copy of this exploit script:
http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
Note the last-mod date of October 21.

No other files on the system were last modified on October 21st.  However
there was a security advisory dated October 20th which affected httpd:
http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update
https://rhn.redhat.com/errata/RHSA-2011-1392.html

and a large number of files on the machine, including lots of files in */
usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* ,
have a last-mod date of October 20th.  So I assume that these are files
which were updated automatically by yum as a result of the patch that goes
with this advisory -- does that sound right?

So a couple of questions that I could use some help with:

1) The last patch affecting httpd was released on October 20th, and the
earliest evidence I can find of the machine being hacked is a file dated
October 21st.  This could be just a coincidence, but could it also suggest
that the patch on October 20th introduced a new exploit, which the attacker
then used to get in on October 21st?
(Another possibility: I think that when yum installs updates, it
doesn't actually restart httpd.  So maybe even after the patch was
installed, my old httpd instance kept running and was still vulnerable? As
for why it got hacked the very next day, maybe the attacker looked at the
newly released patch and reverse-engineered it to figure out where the
vulnerabilities were, that the patch fixed?)

2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5
weeks by default, it looks like any log entries related to how the attacker
would have gotten in on or before October 21st, are gone.  (The secure*
logs do show multiple successful logins as root within the last 4 weeks,
mostly from IP addresses in Asia, but that's to be expected once the
machine was compromised -- it doesn't help track down how they originally
got in.)  Anywhere else that the logs would contain useful data?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On Sun, Jan 1, 2012 at 2:55 PM, Eero Volotinen eero.voloti...@iki.fiwrote:

 2012/1/2 Bennett Haselton benn...@peacefire.org:
  (Sorry, third time -- last one, promise, just giving it a subject line!)
 
  OK, a second machine hosted at the same hosting company has also
 apparently
  been hacked.  Since 2 of out of 3 machines hosted at that company have
 now
  been hacked, but this hasn't happened to any of the other 37 dedicated
  servers that I've got hosted at other hosting companies (also CentOS,
 same
  version or almost), this makes me wonder if there's a security breach at
  this company, like if they store customers' passwords in a place that's
  been hacked.  (Of course it could also be that whatever attacker found an
  exploit, was just scanning that company's address space for hackable
  machines, and didn't happen to scan the address space of the other
 hosting
  companies.)
 
  So, following people's suggestions, the machine is disconnected and
 hooked
  up to a KVM so I can still examine the files.  I've found this file:
  -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
  which appears to be a copy of this exploit script:
  http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
  Note the last-mod date of October 21.
 
  No other files on the system were last modified on October 21st.  However
  there was a security advisory dated October 20th which affected httpd:
 
 http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update
  https://rhn.redhat.com/errata/RHSA-2011-1392.html
 
  and a large number of files on the machine, including lots of files in */
  usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* ,
  have a last-mod date of October 20th.  So I assume that these are files
  which were updated automatically by yum as a result of the patch that
 goes
  with this advisory -- does that sound right?
 
  So a couple of questions that I could use some help with:
 
  1) The last patch affecting httpd was released on October 20th, and the
  earliest evidence I can find of the machine being hacked is a file dated
  October 21st.  This could be just a coincidence, but could it also
 suggest
  that the patch on October 20th introduced a new exploit, which the
 attacker
  then used to get in on October 21st?
 (Another possibility: I think that when yum installs updates, it
  doesn't actually restart httpd.  So maybe even after the patch was
  installed, my old httpd instance kept running and was still vulnerable?
 As
  for why it got hacked the very next day, maybe the attacker looked at the
  newly released patch and reverse-engineered it to figure out where the
  vulnerabilities were, that the patch fixed?)
 
  2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5
  weeks by default, it looks like any log entries related to how the
 attacker
  would have gotten in on or before October 21st, are gone.  (The secure*
  logs do show multiple successful logins as root within the last 4
 weeks,
  mostly from IP addresses in Asia, but that's to be expected once the
  machine was compromised -- it doesn't help track down how they originally
  got in.)  Anywhere else that the logs would contain useful data?

 sshd with root login enabled with very bad password?


 Forgot to mention: the root password was: 1WyJstJZnQ!j   (I have since
changed it).

(I have already practically worn out my keyboard explaining the math behind
why I think a 12-character alphanumeric password is secure enough :) )

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On Sun, Jan 1, 2012 at 4:57 PM, Rilindo Foster rili...@me.com wrote:



 On Jan 1, 2012, at 5:23 PM, Bennett Haselton benn...@peacefire.org
 wrote:

  (Sorry, third time -- last one, promise, just giving it a subject line!)
 
  OK, a second machine hosted at the same hosting company has also
 apparently
  been hacked.  Since 2 of out of 3 machines hosted at that company have
 now
  been hacked, but this hasn't happened to any of the other 37 dedicated
  servers that I've got hosted at other hosting companies (also CentOS,
 same
  version or almost), this makes me wonder if there's a security breach at
  this company, like if they store customers' passwords in a place that's
  been hacked.  (Of course it could also be that whatever attacker found an
  exploit, was just scanning that company's address space for hackable
  machines, and didn't happen to scan the address space of the other
 hosting
  companies.)
 
  So, following people's suggestions, the machine is disconnected and
 hooked
  up to a KVM so I can still examine the files.  I've found this file:
  -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
  which appears to be a copy of this exploit script:
  http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
  Note the last-mod date of October 21.
 
  No other files on the system were last modified on October 21st.  However
  there was a security advisory dated October 20th which affected httpd:
 
 http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update
  https://rhn.redhat.com/errata/RHSA-2011-1392.html
 
  and a large number of files on the machine, including lots of files in */
  usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* ,
  have a last-mod date of October 20th.  So I assume that these are files
  which were updated automatically by yum as a result of the patch that
 goes
  with this advisory -- does that sound right?
 
  So a couple of questions that I could use some help with:
 
  1) The last patch affecting httpd was released on October 20th, and the
  earliest evidence I can find of the machine being hacked is a file dated
  October 21st.  This could be just a coincidence, but could it also
 suggest
  that the patch on October 20th introduced a new exploit, which the
 attacker
  then used to get in on October 21st?
 (Another possibility: I think that when yum installs updates, it
  doesn't actually restart httpd.  So maybe even after the patch was
  installed, my old httpd instance kept running and was still vulnerable?
 As
  for why it got hacked the very next day, maybe the attacker looked at the
  newly released patch and reverse-engineered it to figure out where the
  vulnerabilities were, that the patch fixed?)
 
  2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5
  weeks by default, it looks like any log entries related to how the
 attacker
  would have gotten in on or before October 21st, are gone.  (The secure*
  logs do show multiple successful logins as root within the last 4
 weeks,
  mostly from IP addresses in Asia, but that's to be expected once the
  machine was compromised -- it doesn't help track down how they originally
  got in.)  Anywhere else that the logs would contain useful data?
  ___
  CentOS mailing list
  CentOS@centos.org
  http://lists.centos.org/mailman/listinfo/centos

 Do you have SELinux enabled? If not, you might need to turn that on, as
 that would have prevented that exploit.



I don't, but I'm not sure what you mean by that would have prevented that
exploit.  How do you know what exploit they used, much less that SELinux
would have prevented it?

Or are you assuming that my guess was correct that they got in because of a
vulnerability that was opened up by the patch being auto-installed on
10/20, and that if *that* is the case, that SELinux would have prevented
that?  How does that work, how would SELinux have prevented a vulnerability
being opened up by the patch install?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On Sun, Jan 1, 2012 at 5:33 PM, RILINDO FOSTER rili...@me.com wrote:

 ≈On Jan 1, 2012, at 8:24 PM, Bennett Haselton wrote:

  On Sun, Jan 1, 2012 at 4:57 PM, Rilindo Foster rili...@me.com wrote:
 
 
 
  On Jan 1, 2012, at 5:23 PM, Bennett Haselton benn...@peacefire.org
  wrote:
 
  (Sorry, third time -- last one, promise, just giving it a subject
 line!)
 
  OK, a second machine hosted at the same hosting company has also
  apparently
  been hacked.  Since 2 of out of 3 machines hosted at that company have
  now
  been hacked, but this hasn't happened to any of the other 37 dedicated
  servers that I've got hosted at other hosting companies (also CentOS,
  same
  version or almost), this makes me wonder if there's a security breach
 at
  this company, like if they store customers' passwords in a place that's
  been hacked.  (Of course it could also be that whatever attacker found
 an
  exploit, was just scanning that company's address space for hackable
  machines, and didn't happen to scan the address space of the other
  hosting
  companies.)
 
  So, following people's suggestions, the machine is disconnected and
  hooked
  up to a KVM so I can still examine the files.  I've found this file:
  -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
  which appears to be a copy of this exploit script:
  http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
  Note the last-mod date of October 21.
 
  No other files on the system were last modified on October 21st.
  However
  there was a security advisory dated October 20th which affected httpd:
 
 
 http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update
  https://rhn.redhat.com/errata/RHSA-2011-1392.html
 
  and a large number of files on the machine, including lots of files in
 */
  usr/lib64/httpd/modules/* and
 */lib/modules/2.6.18-274.7.1.el5/kernel/* ,
  have a last-mod date of October 20th.  So I assume that these are files
  which were updated automatically by yum as a result of the patch that
  goes
  with this advisory -- does that sound right?
 
  So a couple of questions that I could use some help with:
 
  1) The last patch affecting httpd was released on October 20th, and the
  earliest evidence I can find of the machine being hacked is a file
 dated
  October 21st.  This could be just a coincidence, but could it also
  suggest
  that the patch on October 20th introduced a new exploit, which the
  attacker
  then used to get in on October 21st?
(Another possibility: I think that when yum installs updates, it
  doesn't actually restart httpd.  So maybe even after the patch was
  installed, my old httpd instance kept running and was still vulnerable?
  As
  for why it got hacked the very next day, maybe the attacker looked at
 the
  newly released patch and reverse-engineered it to figure out where the
  vulnerabilities were, that the patch fixed?)
 
  2) Since the */var/log/httpd/* and /var/log/secure* logs only go back
 4-5
  weeks by default, it looks like any log entries related to how the
  attacker
  would have gotten in on or before October 21st, are gone.  (The secure*
  logs do show multiple successful logins as root within the last 4
  weeks,
  mostly from IP addresses in Asia, but that's to be expected once the
  machine was compromised -- it doesn't help track down how they
 originally
  got in.)  Anywhere else that the logs would contain useful data?
  ___
  CentOS mailing list
  CentOS@centos.org
  http://lists.centos.org/mailman/listinfo/centos
 
  Do you have SELinux enabled? If not, you might need to turn that on, as
  that would have prevented that exploit.
 
 
 
  I don't, but I'm not sure what you mean by that would have prevented
 that
  exploit.  How do you know what exploit they used, much less that SELinux
  would have prevented it?
 
  Or are you assuming that my guess was correct that they got in because
 of a
  vulnerability that was opened up by the patch being auto-installed on
  10/20, and that if *that* is the case, that SELinux would have prevented
  that?  How does that work, how would SELinux have prevented a
 vulnerability
  being opened up by the patch install?

 The script in question is an exploit from a web board which is apparently
 designed to pull outside traffic. If you had SELinux, it would put httpd in
 its own context and by default, it will NOT allow connections from that
 context to another. You have to enable it with:

 setsebool -P httpd_can_network_connect on


I'm not sure what you mean by an exploit from a web board which is
apparently designed to pull outside traffic.  Like Ljubomir said, it looks
like a script that is used from machine X to DOS attack machine Y, if
machine Y has the VBulletin bulletin board software installed on it.  Is
that what you meant? :)

But anyway, since the file was located at /home/file.pl (and since attacker
had console access

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On Sun, Jan 1, 2012 at 5:01 PM, Les Mikesell lesmikes...@gmail.com wrote:

 On Sun, Jan 1, 2012 at 4:23 PM, Bennett Haselton benn...@peacefire.org
 wrote:
 
  So, following people's suggestions, the machine is disconnected and
 hooked
  up to a KVM so I can still examine the files.  I've found this file:
  -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl
  which appears to be a copy of this exploit script:
  http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html
  Note the last-mod date of October 21.

 Did you do an rpm -Va to see if any installed files were modified
 besides your own changes?  Even better if you have an old backup that
 you can restore somewhere and run an rsync -avn against the old/new
 instances.



rpm -Va gives:

L...  c /etc/pam.d/system-auth
S.5T  c /etc/httpd/conf.d/ssl.conf
SM5...GT  c /etc/squid/squid.conf
S.5T  c /etc/login.defs
S.5T  c /etc/ssh/sshd_config
S.5T  c /etc/httpd/conf.d/welcome.conf
S.5T  c /etc/httpd/conf/httpd.conf
S.5.  c /etc/ldap.conf
S.5.  c /etc/openldap/ldap.conf
L...  c /etc/pam.d/system-auth
...T  c /etc/audit/auditd.conf
S.5T  c /etc/printcap
S.5T  c /etc/yum/yum-updatesd.conf
S.5.  c /etc/ldap.conf
S.5.  c /etc/openldap/ldap.conf


According to
http://www.rpm.org/max-rpm/s1-rpm-verify-output.html
many config files do not verify successfully (and I recognize some of them
from modifying them manually, and others presumably could have been
modified by the hosting company).

I don't have a backup since there is no data stored only on the machine, so
if anything is lost on the machine I just ask the host to re-format it and
then re-upload everything.



   Anywhere else that the logs would contain useful data?

 /root/.bash_history might be interesting.  Obviously this would be
 after the fact, but maybe they are trying to repeat the exploit with
 this machine as a base.




Good idea but it only shows the commands that I've run since logging in to
try and find out what happened.  Perhaps the attacker wiped
/root/.bash_history after getting in.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On Sun, Jan 1, 2012 at 6:03 PM, Fajar Priyanto fajar...@arinet.org wrote:

 On Mon, Jan 2, 2012 at 9:33 AM, RILINDO FOSTER rili...@me.com wrote:
  The script in question is an exploit from a web board which is
 apparently designed to pull outside traffic. If you had SELinux, it would
 put httpd in its own context and by default, it will NOT allow connections
 from that context to another. You have to enable it with:

 The only time my server got hacked was because of phpBB. Using
 cross-site scripting, the hacker managed to put a pl file and when I
 ran it, it opened a console.
 Apparently you are running one of the web boards.


I'm not running phpBB or vBulletin.  The script apparently runs on machine
X to attack a *different* machine Y where machine Y has vBulletin installed
on it.


 Pls follow up any
 security advisories of that product and any addon/module closely.

 If you are really curious how yours got hack. You can setup similar
 system and put a bounty (maybe $1000) in one of the underground
 community for anyone to hack it and tell you how they do it.




Is there a non-underground place to post such requests?  It's not illegal
to offer a bounty to someone for finding a security hole in your system --
Facebook, Google, and Mozilla all do it.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] why not have yum-updatesd running by default?

[Bennett Haselton]

On Wed, Dec 28, 2011 at 11:33 AM, Jim Wildman j...@rossberry.com wrote:

 The 'E' in CentOS stands for Enterprise.  Enterprises use change
 control.  Servers do not update themselves whenever they see an update.
 Updates are tested (not so much), approved and scheduled, hopefully in
 line with a maintenance window.  In most enterprises that I've been in,
 a server can't even contact the default repo servers.  And remember that
 for a RHEL server, it has to be registered with RHN before it can
 officially receive updates.  Defaulting yum-updatesd to on will be a no-op
 in almost every 'enterprise' case.

 Enterprises also don't hang servers directly off the Internet.  There
 are many layers betwixt the wild web and the OS.

 In the decade plus that I've been running RHEL, I've seen 1 update that
 was worthy of an emergency change to push it out RIGHT NOW to the
 servers.  And even that one didn't really need to be done.

 --
 Jim Wildman, CISSP, RHCE   j...@rossberry.com http://www.rossberry.net
 Society in every state is a blessing, but Government, even in its best
 state, is a necessary evil; in its worst state, an intolerable one.
 Thomas Paine
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos


To be more clear, I wasn't saying that for the particular people on this
list, of whom many are professional sysadmins, that it would be the best
option.

I'm talking about the majority of users who have leased a dedicated server
or a VPS for $5-$50 per month, and cannot ever be realistically expected to
change much of the defaults.  In that situation, you're weighing the
likelihood, and the undesirability, of two outcomes: either (1) the machine
ends up going down temporarily because of a bad update, or (2) the machine
ends up being hacked and attacking other networks because it wasn't
receiving updates.

(Side note: my friend replied to clarify that the kernel exploit he was
talking about that was found in March of this year, was one that allowed a
local user to gain root privilege, not one that allowed a remote user to
get in through the webserver or sshd.  So let's say it really is true
that running automatic yum updates is not the most important thing to
keep out remote users, and that the majority of webserver hacks do occur
through out-of-date web apps.  Then replace everything I said with update
the web apps instead of installing the yum update patches.)

Would it not be best for the vast majority of those users to have updates
turned on by default?  If not, why not?  (Power users can always turn them
off, after all.)

Look, one may think that root access to dedicated servers (and
virtual/dedicated servers, which are almost as powerful/dangerous) should
never be given out to people who haven't been professionally trained.
(Some people still say that about net-connected computers generally!)  But
that can never be rolled back now, as long as hosting companies can legally
sell unmanaged dedicated/VPS machines to the public, they will.  So what
can be done to reduce the risks?

Or look at it this way: Suppose the government or some foundation offered a
$1 million prize for any proposal that permanently lowered the rate at
which CentOS servers were compromised.  If you actually come up with a
solution that lowers the rate, you get the money, but if you say that all
end users should do such-and-such (and they don't), then you get
nothing.  What would your proposal be?

My suggestion would be:
1) Implement an API call on the OS for send this message to the machine
owner.  When the OS is installed on the machine, the person installing it
decides how the notify call would be implemented -- send an email to an
address, send a SMS message, whatever.  If a hosting company sets it up,
they could implement the call so that it automatically opens a new support
ticket waiting for the customer's attention.
The reason for #1 is that if the OS wants to notify the machine admin that
there's a problem, then -- at least in the case of a remotely hosted cheap
server or VPS -- you can't rely on the admin logging in and seeing the
message.  You have to proactively grab their attention somehow.  Then you
could use this function call for lots of things, but most importantly for
#2:
2) Implement some sort of scanner program (enabled by default) that would
regularly scan the machine, not just for known viruses, but for *anything*
that was known to be a frequent vector for attacks, that was not configured
to update itself automatically.  And:
- If the scanner finds an app that is not configured to update itself
automatically, it sends a low-priority message (using #1) saying There are
no known exploits for this thing right now, but you really ought to turn on
updates for it.
- If the scanner finds a web app like WordPress that *cannot* update itself
automatically, say This 

Re: [CentOS] what percent of time are there unpatched exploits against default config?

[Bennett Haselton]

On Wed, Dec 28, 2011 at 6:10 AM, Johnny Hughes joh...@centos.org wrote:

 On 12/27/2011 10:42 PM, Bennett Haselton wrote:
  Everything installed on the machine had been installed with yum.  So I
  assumed that meant that it would also be updated by yum if an update
 was
  available from the distro.
 

 1.  Are you running PHP apps on the web server?  Perl apps?  Bad code in
 dynamic apps is the main way security breaches happen if via apache.
 And in those cases is usually the ability to execute some script
 (sometimes one that the bad guys upload first) that is the issue.  Many
 times this happens because programmers of the dynamic (php, perl,
 python, ruby, etc.) do not properly vet the input of some form or other
 item.


The only popular third-party script on the server was glype from
www.glype.com.  I don't know if it's popular enough (compared to, say,
WordPress) to make it worthwhile for the bad guys to have developed an
exploit against it.  On the other hand, if they used an automated tool that
can be pointed to *any* PHP script and probe it for weaknesses, they could
have found something.








2.  Why have password logins at all?  Using a secure ssh key only for
 logins makes the most sense.


Well that's something that I'm curious about the reasoning behind -- if
you're already using a completely random 12-character password, why would
it be any more secure to use an ssh key?  Even though the ssh key is more
random, they're both sufficiently random that it would take at least
hundreds of years to get in by trial and error.




3.  Please do not top post.


My bad.  Gmail default. :)



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] why not have yum-updatesd running by default?

[Bennett Haselton]

On Thu, Dec 29, 2011 at 10:49 AM, Les Mikesell lesmikes...@gmail.comwrote:

  Would it not be best for the vast majority of those users to have updates
  turned on by default?  If not, why not?  (Power users can always turn
 them
  off, after all.)

 If your service is important, then it is worth testing changes before
 making them on your important server.   But no one else can tell you
 whether your server is that important or not...   It's fairly trivial
 to run a 'yum update' on a lab server daily, and if anything  updates,
 make sure that things still work before repeating it on the production
 box(es).   The update checks can be scripted, but the does it still
 work test will be unique to your services.


But these are all considerations mainly for power users; I'm still talking
just about the vast majority of hosting company customers who just lease a
dedicated or virtual private server, and don't even have a test server
and a production server.  Why wouldn't it be best for those servers just
to pick up and install updates automatically?


  What would your proposal be?  (Remembering that you can't change human
  nature, so if it relies on the majority of end users devoting time that
 you
  think they should do, it won't happen :) )

 Mine is to assume that there are very good reasons for 'Enterprise'
 distributions to go to the trouble of publishing updates.  Install
 them.  Always assume that there are still more vulnerabilities that
 you don't know about yet - and if you have to ask the question, you
 aren't going to do better than the developers and Red Hat at keeping
 up with them.




Yes this is good advice for the individual user; what I was asking is what
set of *defaults* would improve security the most for the vast majority of
users (who cannot be counted on to change defaults -- or, indeed, to follow
any advice that anyone thinks everyone should do!).
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] why not have yum-updatesd running by default?

[Bennett Haselton]

Ever since someone told me that one of my servers might have been hacked
(not the most recent instance) because I wasn't applying updates as soon as
they became available, I've been logging in and running yum update
religiously once a week until I found out how to set the yum-updatesd
service to do the equivalent automatically (once per hour, I think).

Since then, I've leased dedicated servers from several different companies,
and on all of them, I had to set up yum-updatesd to run and check for
updates -- by default it was off.  Why isn't it on by default?  Or is it
being considered to make it the default in the future?

Power users can always change it if they want; the question is what would
be better for the vast majority of users who don't change defaults.  In
that case it would seem better to have updates on, so that they'll get
patched if an exploit is released but a patch is available.

If the risk is that a buggy update might crash the machine, then that has
to be weighed against the possibility of *not* getting updates, and getting
hacked as a result -- usually the latter being worse.

After all, if users are exhorted to log in to their machines and check for
updates and apply them, that implies that the risk of getting hosed by a
buggy update is outweighed by the risk of getting hacked by not applying
updates.  If that's true for updates that are applied manually, it ought to
be true for updates that are downloaded and applied automatically,
shouldn't it?

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] what percent of time are there unpatched exploits against default config?

[Bennett Haselton]

Suppose I have a CentOS 5.7 machine running the default Apache with no
extra modules enabled, and with the yum-updatesd service running to pull
down and install updates as soon as they become available from the
repository.  (Assume further the password is strong, etc.)  On the other
hand, suppose that as the admin, I'm not subscribed to any security alert
mailing lists which send out announcements like Please disable this
feature as a workaround until this hole is plugged, so the machine just
hums along with all of its default settings.

So the machine can still be broken into, if there is an unpatched exploit
released in the wild, in the window of time before a patch is released for
that update.  On the other hand, at any point in time where there are no
unpatched exploits in the wild, the machine should be much harder to break
into.

Roughly what percent of the time is there such an unpatched exploit in the
wild, so that the machine can be hacked by someone keeping up with the
exploits?  5%?  50%?  95%?

Hopefully this is specific enough that the answer is not it depends :) ,
an actual numeric answer should exist -- although I don't know if anyone
has ever tried to work it out.  But if not, then what's a good guess, based
on observing how frequently root exploits are released in the wild, and how
long the patches usually take.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] what percent of time are there unpatched exploits against default config?

[Bennett Haselton]

On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste 
seben...@weather.admin.niu.edu wrote:

 On Tue, 27 Dec 2011, Bennett Haselton wrote:

  Suppose I have a CentOS 5.7 machine running the default Apache with no
  extra modules enabled, and with the yum-updatesd service running to
 pull
  down and install updates as soon as they become available from the
  repository.
 
  So the machine can still be broken into, if there is an unpatched exploit
  released in the wild, in the window of time before a patch is released
 for
  that update.
 
  Roughly what percent of the time is there such an unpatched exploit in
 the
  wild, so that the machine can be hacked by someone keeping up with the
  exploits?  5%?  50%?  95%?

 There's no way to give you an exact number, but let me put it this way:

 If you've disable as much as you can (which by default, most stuff is
 disabled, so that's good), and you restart Apache after each update,
 your chances of being broken into are better by things like SSH brute
 force attacks. There's always a chance someone will get in, but when you
 look at the security hole history of Apache, particularly over the past
 few years, there have been numerous CVE's, but workarounds and they aren't
 usually earth-shattering. Very few of them have. The latest version that
 ships with 5.7 is as secure as they come. If it wasn't, most web sites
 on the Internet would be hacked by now, as most run Apache


I was asking because I had a server that did get broken into, despite
having yum-updatesd running and a strong password.  He said that even if
you apply all latest updates automatically, there were still windows of
time where an exploit in the wild could be used to break into a machine; in
particular he said:

For example, there was a while back ( ~march ) a kernel exploit that
affected CentOS / RHEL. The patch came after 1-2 weeks of the security
announcement. The initial announcement provided a simple work around until
the new version is released.

Was this a sufficiently high-profile incident that you know what he's
referring to?  If this kind of thing happens once a year or more, than
surely this is a much greater threat than brute forcing the SSH
password?  That's what I'm talking about -- how often does this sort of
thing happen, where you need to be subscribed to be a security mailing list
in order to know what workaround to make to stay safe, as opposed to simply
running yum-updatesd to install latest patches automatically.

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] what percent of time are there unpatched exploits against default config?

[Bennett Haselton]

Everything installed on the machine had been installed with yum.  So I
assumed that meant that it would also be updated by yum if an update was
available from the distro.

On Tue, Dec 27, 2011 at 9:38 PM, Karanbir Singh mail-li...@karan.orgwrote:

 On 12/28/2011 04:29 AM, Bennett Haselton wrote:
  I was asking because I had a server that did get broken into, despite
  having yum-updatesd running and a strong password.  He said that even if

 the software component compromised was a part of the updates being
 dished out from the distro ( and therefore likely covered via the
 yum-updatesd? )

 - KB
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] what percent of time are there unpatched exploits against default config?

[Bennett Haselton]

Yeah I know that most break-ins do happen using third-party web apps;
fortunately the servers I'm running don't have or need any of those.

But then what about what my friend said:
For example, there was a while back ( ~march ) a kernel exploit that
affected CentOS / RHEL. The patch came after 1-2 weeks of the security
announcement. The initial
announcement provided a simple work around until the new version is
released.
Is that an extremely rare freak occurrence?  Or are you just saying it's
rare *compared* to breakins using web apps?  Or am I misunderstanding what
my friend was referring to in the above paragraph?

Bennett

2011/12/27 夜神 岩男 supergiantpot...@yahoo.co.jp

 On 12/28/2011 01:29 PM, Bennett Haselton wrote:
  On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste
  seben...@weather.admin.niu.edu  wrote:
 
  On Tue, 27 Dec 2011, Bennett Haselton wrote:
 
  Suppose I have a CentOS 5.7 machine running the default Apache with no
  extra modules enabled, and with the yum-updatesd service running to
  pull
  down and install updates as soon as they become available from the
  repository.
 
  So the machine can still be broken into, if there is an unpatched
 exploit
  released in the wild, in the window of time before a patch is released
  for
  that update.
 
  Roughly what percent of the time is there such an unpatched exploit in
  the
  wild, so that the machine can be hacked by someone keeping up with the
  exploits?  5%?  50%?  95%?
 
  There's no way to give you an exact number, but let me put it this way:
 
  If you've disable as much as you can (which by default, most stuff is
  disabled, so that's good), and you restart Apache after each update,
  your chances of being broken into are better by things like SSH brute
  force attacks. There's always a chance someone will get in, but when you
  look at the security hole history of Apache, particularly over the past
  few years, there have been numerous CVE's, but workarounds and they
 aren't
  usually earth-shattering. Very few of them have. The latest version that
  ships with 5.7 is as secure as they come. If it wasn't, most web sites
  on the Internet would be hacked by now, as most run Apache
 
 
  I was asking because I had a server that did get broken into, despite
  having yum-updatesd running and a strong password.  He said that even if
  you apply all latest updates automatically, there were still windows of
  time where an exploit in the wild could be used to break into a machine;
 in
  particular he said:
 
  For example, there was a while back ( ~march ) a kernel exploit that
  affected CentOS / RHEL. The patch came after 1-2 weeks of the security
  announcement. The initial announcement provided a simple work around
 until
  the new version is released.
 
  Was this a sufficiently high-profile incident that you know what he's
  referring to?  If this kind of thing happens once a year or more, than
  surely this is a much greater threat than brute forcing the SSH
  password?  That's what I'm talking about -- how often does this sort of
  thing happen, where you need to be subscribed to be a security mailing
 list
  in order to know what workaround to make to stay safe, as opposed to
 simply
  running yum-updatesd to install latest patches automatically.

 Nearly every time servers get broken into they are web servers, and web
 servers serving applications the greatest percentage of those. The web
 never having been intended as an applications platform provides a huge
 number of attack vectors which are entirely separate from the OS layer.

 For example, a perfectly secure operating system running a perfectly
 secure Apache configuration on a perfectly secure MySQL deployment could
 be running an application that permits injection of arbitrary SQL
 commands into the database. The server itself may not be compromised (or
 it may, depending on what else that SQL command can touch/be referenced
 by) in the sense that someone can open a shell, but in most cases there
 is nothing of interest on a web server anyway. What is interesting is
 what is in the database or lives within the application being served,
 and that is an application/database layer problem, not an OS, web-server
 or kernel problem.

 With the vast majority of web applications being developed on frameworks
 like Drupal, Django and Plone, the overwhelming majority of server
 hacks with regard to the web have to do with attacking these structures
 (at least initially), not the actual OS layer directly at the outset.

 Compare this with email server software, which, if the OS layer were the
 inherent problem, would be heard about every day -- much more often than
 web-related cracks. But email server software is mature and just as
 secure as Apache is. However, web-based email is a common target, and
 for a good reason. http is inherently insecure, and bouncing someone
 from http to https is just as insecure because the initial http link and
 DNS can be attacked, both being

Re: [CentOS] what percent of time are there unpatched exploits against default config?

[Bennett Haselton]

On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster rili...@me.com wrote:





 On Dec 27, 2011, at 11:29 PM, Bennett Haselton benn...@peacefire.org
 wrote:

  On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste 
  seben...@weather.admin.niu.edu wrote:
 
  On Tue, 27 Dec 2011, Bennett Haselton wrote:
 
  Suppose I have a CentOS 5.7 machine running the default Apache with no
  extra modules enabled, and with the yum-updatesd service running to
  pull
  down and install updates as soon as they become available from the
  repository.
 
  So the machine can still be broken into, if there is an unpatched
 exploit
  released in the wild, in the window of time before a patch is released
  for
  that update.
 
  Roughly what percent of the time is there such an unpatched exploit in
  the
  wild, so that the machine can be hacked by someone keeping up with the
  exploits?  5%?  50%?  95%?
 
  There's no way to give you an exact number, but let me put it this way:
 
  If you've disable as much as you can (which by default, most stuff is
  disabled, so that's good), and you restart Apache after each update,
  your chances of being broken into are better by things like SSH brute
  force attacks. There's always a chance someone will get in, but when you
  look at the security hole history of Apache, particularly over the past
  few years, there have been numerous CVE's, but workarounds and they
 aren't
  usually earth-shattering. Very few of them have. The latest version that
  ships with 5.7 is as secure as they come. If it wasn't, most web sites
  on the Internet would be hacked by now, as most run Apache
 
 
  I was asking because I had a server that did get broken into, despite
  having yum-updatesd running and a strong password.  He said that even if
  you apply all latest updates automatically, there were still windows of
  time where an exploit in the wild could be used to break into a machine;
 in
  particular he said:
 
  For example, there was a while back ( ~march ) a kernel exploit that
  affected CentOS / RHEL. The patch came after 1-2 weeks of the security
  announcement. The initial announcement provided a simple work around
 until
  the new version is released.
 

 What was the nature of the break-in, if I may ask?


I don't know how they did it, only that the hosting company had to take the
server offline because they said it was sending a DOS attack to a remote
host and using huge amounts of bandwidth in the process.  The top priority
was to get the machine back online so they reformatted it and re-connected
it, so there are no longer any logs showing what might have happened.
(Although of course once the server is compromised, presumably the logs can
be rewritten to say anything anyway.)

 Security is more than just updates and a strong password.

  - Rilindo Foster


Well that's what I'm trying to determine.  Is there any set of default
settings that will make a server secure without requiring the admin to
spend more than, say, 30 minutes per week on maintenance tasks like reading
security newsletters, and applying patches?  And if there isn't, are there
design changes that could make it so that it was?

Because if an OS/webserver/web app combination requires more than, say,
half an hour per week of maintenance, then for the vast majority of
servers and VPSs on the Internet, the maintenance is not going to get
done.  It doesn't matter what our opinion is about whose fault it is or
whether admins should be more diligent.  The maintenance won't get done
and the machines will continue to get hacked.  (And half an hour per week
is probably a generous estimate of how much work most VPS admins would be
willing to do.)

On the other hand, if the most common causes of breakins can be identified,
maybe there's a way to stop those with good default settings and automated
processes.  For example, if exploitable web apps are a common source of
breakins, maybe the standard should be to have them auto-update themselves
like the operating system.  (Last I checked, WordPress and similar programs
could *check* if updates were available, and alert you next time you signed
in, but they didn't actually patch themselves.  So if you never signed in
to a web app on a site that you'd forgotten about, you might never realize
it needed patching.)

Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] what percent of time are there unpatched exploits against default config?

[Bennett Haselton]

On Tue, Dec 27, 2011 at 10:08 PM, Ken godee k...@perfect-image.com wrote:

  password?  That's what I'm talking about -- how often does this sort of
  thing happen, where you need to be subscribed to be a security mailing
 list
  in order to know what workaround to make to stay safe, as opposed to
 simply
  running yum-updatesd to install latest patches automatically.

 Happens all the time!


Really?  An exploit is released in the wild, and there's a lag of several
days before a patch is available through updates -- all the time?  How
often?  Every week?

Since Gilbert and supergiantpotato seemed to be saying the opposite (that
unpatched OS- and web-server-level exploits were pretty rare), what data
were you relying on when you said that it happens all the time?


 Count on it! If running any server available to
 the public there is no set and forget if you're responsible for that
 server you best stay informed/subscribed and ready to take action be it
 a work around, update or whatever.



 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos