Re: package for security advice

[Russell Coker]

On Saturday, 7 March 2020 11:39:05 PM AEDT vi...@vheuser.com wrote:
> Isn't this what Tiger does?
> 
> apt-cache search tiger
> 
> tiger - Report system security vulnerabilities
> tiger-otheros - Scripts to run Tiger in other operating systems

Tiger is something that the tool I'm proposing could suggest or recommend.  
Thanks for mentioning Tiger, it's something I need to include in this.

But Tiger is just covering part of it.  I want to have a central place for 
recommending security improvements covering a variety of configuration issues, 
the vast majority of which won't be vulnerabilities.  One of the aims is to 
have a hardened configuration that is less likely to have problems in the face 
of unexpected future security issues.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

package for security advice

[Russell Coker]

I think it would be good to have a package for improving system security.  It 
could depend on packages like spectre-meltdown-checker and also contain 
scripts that look for ways of improving system security.  For example 
recommend SE Linux or Apparmor (if you don't have one installed), recommend 
lockdown=confidentiality if using kernel 5.4 or greater, and do other similar 
checks and warnings.  For each issue there would ideally be a URL provided 
(maybe to the Debian Wiki, maybe to somewhere else) that describes the issue.  
I'm not saying that everyone should use all these features, just that everyone 
who cares about security should know what the options are and have made an 
informed choice that they can easily review.

For subsystems that are complex and security critical (like Apache and Samba 
for example) you could have other packages providing check scripts that look 
for common configuration choices that might reduce security.  Such scripts 
would be designed to give false positives rather than false negatives.  The 
idea being that if you do something potentially risky then you should be aware 
of it and so should whoever takes over your job in a few years time.  Then at 
relevant times (EG after an upgrade to a new release of Debian) decisions 
about security can be reviewed.

What do you think about this idea?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: Intel Microcode updates

[Russell Coker]

On Monday, 10 June 2019 9:16:02 PM AEST Michael Stone wrote:
> Your CPU is not supported my Intel, so you either accept the risk or buy
> a new one. (Note that the latest version of the microcode is from
> 2015--long before any of these speculative execution vulnerabilities
> were mitigated.) Yours is a yorkfield:
> https://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/

Thanks for the advice.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930319

I've filed a bug against the spectre-meltdown-checker package wishing for such 
information to be included.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: Intel Microcode updates

[Russell Coker]

On Tuesday, 11 June 2019 12:19:14 PM AEST Henrique de Moraes Holschuh wrote:
> On Mon, 10 Jun 2019, Russell Coker wrote:
> > model name  : Intel(R) Core(TM)2 Quad CPUQ9505  @ 2.83GHz
> > 
> > On a system with the above CPU running Debian/Testing I get the following
> > results from the spectre-meltdown-checker script.  Is this a bug in the
> > intel- microcode package that the latest version isn't packaged?  There
> > is no newer version of intel-microcode in Unstable.
> 
> Intel upstream decided to not distribute it, for whatever reason.  The
> Core2 will not get any fixes for MDS either (nor will Nehalem and
> Westmere).
> 
> It is easy enough to source that microcode update if you look for it,
> and you can just drop it on /usr/share/misc/intel-microcode.bin with
> intel-microcode installed, and update the initramfs.  It will pick the
> extra microcode up.

Should it be regarded as a bug in the intel-microcode package that it doesn't 
have this update that is "easy enough to source"?  Or do you mean "easy to get 
but not licensed for distribution"?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Intel Microcode updates

[Russell Coker]

I just discovered the spectre-meltdown-checker package (thanks Sylvestre for 
packaging this).

model name  : Intel(R) Core(TM)2 Quad CPUQ9505  @ 2.83GHz

On a system with the above CPU running Debian/Testing I get the following 
results from the spectre-meltdown-checker script.  Is this a bug in the intel-
microcode package that the latest version isn't packaged?  There is no newer 
version of intel-microcode in Unstable.

# spectre-meltdown-checker |grep CPU.mic
* Hardware support (CPU microcode) for mitigation techniques
  * CPU microcode is known to cause stability problems:  NO  (model 0x17 
family 0x6 stepping 0xa ucode 0xa0b cpuid 0x1067a)
  * CPU microcode is the latest known available version:  NO  (latest version 
is 0xa0e dated 2015/07/29 according to builtin MCExtractor DB v111 - 
2019/05/18)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, 
but your CPU microcode doesn't support it
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this 
vulnerability)
* CPU microcode mitigates the vulnerability:  N/A 

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: HTTPS enabled Debian Security repository

[Russell Coker]

On Monday, 30 October 2017 8:57:00 AM AEDT Hans-Christoph Steiner wrote:
> > The one from 2016 is harder to exploit: I asked on #-apt back then and
> > the sample exploit had a 1/4 success change with a 1.3 GB InRelease file
> > on a memory starved i386 system).
> 
> That hit rate is enough to build malware around...

25% hit rate is enough to be worth exploiting, but 1.3G of extra data greatly 
reduces the incidence.  The small i386 systems tend not to have fast enough 
networking that 1.3G of data could be downloaded without notice.

> Don't get me wrong, I agree that HTTPS is very overcomplicated and
> terrible in a lot of ways.  But the days of plain HTTP/TCP are over.
> All connections need to be moving towards encryption.  Even with HTTPS'
> faults, we are better off using it than plain HTTP.

I agree.  There's little downside nowadays.  Squid doesn't work particularly 
well caching APT repositories nowadays (strange timeouts and hangs during 
downloads) so the caching benefit of non-SSL has mostly gone away.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: Iptables

[Russell Coker]

On Fri, 31 Mar 2017 09:44:01 PM R Calleja wrote:
> can anybody help me. I have security issues and I have to reinstall
> the system every year.
> Set up a firewall with iptables as the attachment and now block
> connections as you can see in the dmesg attachment.

Debian-user is probably a better list for this, or ask for help at your local 
LUG.

As a general rule firewalls don't stop systems being compromised.  A 
desktop/laptop system generally requires a local user to perform so much 
network access that there's nothing that can be usefully blocked.

Also blocking all ICMP isn't going to help you, the "ping of death" bug has 
been fixed.  Buffer overflows are not restricted to ICMP, it's been a problem 
in 
most protocols in various ways.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

[Russell Coker]

On Sunday, 29 January 2017 8:07:09 PM AEDT Santiago Vila wrote:
> IMO, if we want reproducible builds and we don't want this to happen,
> we should probably change the way we do binNMUs (where "change" could
> well be not doing binNMUs at all and always include full and exact
> source with every upload).

Why is it desirable to have bunNMUs anyway?  For small packages there's little 
overhead in just rebuilding it on all architectures.  For complex packages I 
think that it's best to avoid the potential problems of binNMUs in terms of 
tracking changes etc.  Things like LibreOffice and the kernel are complex 
enough without having binary changes that lack a changelog entry.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: Security features in the upcoming release (Stretch)

[Russell Coker]

My plan is to have the KDE and GNOME desktop environments working with SE Linux 
enforcing mode on Stretch along with the most important apps such as Google 
Chrome/Chromium.

I hope to have something ready to test in Unstable in a few weeks.

On 23 September 2016 11:21:55 pm AEST, "m.la...@t-online.de" 
 wrote:
>Hi everybody,
>is there already some evidence about security improvements in the
>upcoming Debian release? I took a look at the security feature page in
>the Wiki [1] but Stretch is not listed there. Furthermore, the list is
>not as complete as the list of Fedora [2]. Is there somebody with an
>insight into the actual state of security in Debian willing to complete
>this list? Or are not as many security features implemented as in
>Fedora?
>
>Secondly, what is about the policies for SELinux and Apparmor? Will
>there be working SELinux policies (like in RHEL or Fedora) with Stretch
>which work out of the box (like in RHEL or Fedora) on a desktop system?
>
>Finally, which of the new kernel security features (since the release
>of Jessie) will be enforced in Stretch? Are there plans to migrate some
>kernel hardening from PaX to Debian Stretch? 
>
>Generally, it would be nice to find more information about proactive
>security measures which are provided by Debian. For me as a user and
>admin, it is very difficult to assess the level of proactive security
>in Debian in comparison to other major distros like Fedora or RHEL /
>CentOS. Therefore, I think it would be great if the wiki page can be
>expanded.
>
>Thank you very much for your answers in advance and also if there is
>somebody who is able to complete the wiki page.
>
>Yours, 
>Maximilian
>
>Hyperlinks
>--
>[1] https://wiki.debian.org/Security/Features
>[2] https://fedoraproject.org/wiki/Security_Features_Matrix
>
>
>
>
>
>
>Gesendet mit Telekom Mail  -
>kostenlos und sicher für alle!

-- 
Sent from my Nexus 6P with K-9 Mail.

Re: SELinux in Jessie??

[Russell Coker]

On Mon, 4 May 2015, Paul Wise  wrote:
> On Mon, May 4, 2015 at 12:20 AM, Bart-Jan Vrielink wrote:
> > Where can I find a suitable policy? The package selinux-policy-default is
> > no longer available, and I cannot find a suitable replacement in
> > Jessie/main.
> 
> The package was removed before jessie as it had release critical bugs
> and no maintainer action. Please contact the maintainers about this
> issue, perhaps they will be willing to fix the RC bugs and upload to
> jessie-backports.
> 
> https://bugs.debian.org/src:refpolicy

I'm working on this now.  Sorry for the delay.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

[Russell Coker]

On Sun, 1 Feb 2015 11:18:43 PM Paul Wise wrote:
 chromium was already being backported to wheezy for security updates,
 the latest versions need newer compilers so we can't backport any
 more.

Why can't we backport the compilers too?


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201502020252.36485.russ...@coker.com.au

Re: NSA software in Debian

[Russell Coker]

On Fri, 24 Jan 2014, Marko Randjelovic marko...@eunet.rs wrote:
  I would also like this. Yesterday I started compiling 3.2.54 with grsec
  and PaX. A ready debian kernel(-source) with grsec and PaX would be
  fine. Currently I am distributing my special packages via my own
  repository - is there any concern when making it public (copyright,
  etc.)?
 
 I managed to do it from official kernel 3.2.51-1. I removed all
 features/* patches without consideration because there were to many of
 them (905). Than I had to remove many other patches to resolve
 conflicts. If patch file f is patched consequently by patches p1, p2,
 if patch p1 is removed, then p2 may fail.

The correct thing to do is just prepare a GRSecurity patch that applies on top 
of the Debian kernel patches.  At one time (10+ years ago) I was maintaining 
patches for GRSecurity and LSM/SELinux and doing this for every new Debian 
kernel package and new version of GRSecurity and LSM/SELinux.

http://packages.debian.org/jessie/linux-patch-grsecurity2

The above package looks like it needs some work.  The description doesn't 
appear to have been updated since LSM became part of the main kernel tree and 
it references kernel 2.4.x.

Really what this all depends on is having people in Debian with the spare time 
and kernel coding skill needed to just make the patches in question work.  If 
the above package doesn't cleanly apply against the kernel you want to use 
then you could join in the coding work.

I think that anyone who has enough skill in kernel issues that the absense of 
LSM hooks will provide them with an advantage when dealing with attackers 
should be able to do such coding easily.

Marko it might be best if you have an off-list discussion with Laszlo about 
how his package doesn't meet your requirements and how you might help him with 
the coding.

Laszlo, please don't take this as criticism.  I know that maintaining such a 
kernel patch for Debian is a difficult project, you have to deal with two 
different upstreams that move at different speeds.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201401282029.52340.russ...@coker.com.au

Re: NSA software in Debian

[Russell Coker]

On Sun, 19 Jan 2014, Marco Saller marcosal...@yahoo.de wrote:
 i am not sure if this question has been asked or answered yet, please do
 not mind if i would ask it again. Is it possible that the NSA or other
 services included investigative software in some Debian packages?

It is possible that a DD has betrayed the cause and willingly subverted a 
package, in the past we had someone apply to become a DD who had a history of 
doing such things.  Fortunately they were caught and didn't become a DD, but 
it's possible that someone else with similar ideas got through.  This doesn't 
make Debian any different to any other large project or organisation.  Getting 
1000+ people to work together and have no-one do crazy stuff is an impossible 
problem to solve.

It's possible that a DD with good intentions has been blackmailed by an 
external organisation.  Again that's the same with any organisation.

One advantage that Debian has over proprietary software companies is that 
there's no possibility of someone accepting a $10,000,000 payment and making 
it policy to weaken Debian security the way that some proprietary software was 
deliberately weakened.

On Sun, 19 Jan 2014, Noah Meyerhans no...@debian.org wrote:
 It is absolutely possible. It's even possible that you yourself have
 added such software to Debian! Can you prove that you haven't?
 
 That line of thinking leads to madness. The only rational conclusion,
 once you start down that path, is to turn off your computers and move to
 a remote cabin in the wilderness. It will never be possible to prove
 that there is no malicious software in Debian or in any other OS. Beyond
 that, it will never be possible to prove that there is no malicious
 *hardware* running executing your OS.
 
 We can and do take care to ensure that all changes to Debian are made by
 people authorized to make those changes. (Package uploads must be signed
 by a Debian developer.) We can and do take care to ensure that that the
 packages you download have not been modified in transmission (signing of
 Release files, checksums on Packages files and on packages themselves.)
 Etc. If deficiencies are found in our mechanisms or policies, then we
 take steps to improve them. If violations are found, then we take steps
 to audit for impact and resolve any potentially malicious actions that
 we identify. We take great care to minimize the likelihood of any sort
 of backdoor or malicious code in Debian, but none of this can provide
 100% proof that such a thing doesn't exist. Anybody that claims that
 they can prove otherwise, for Debian or any other OS, is either lying or
 ignorant.

Absolutely.

On Sun, 19 Jan 2014, Justin Andrusk jandr...@gmail.com wrote:
 I would expect it to be root kit of some form, most likely to dwell in a
 non-free repo.

The vast majority of Linux systems are single-user systems.  If a hostile 
party gains access to the UID that's used for running one web browser, email 
program, game, etc then they get it all.  So getting root isn't required for 
most hostile activity.  That gives a much larger scope for attackers and a 
much more difficult problem for the people who defend systems.

One thing to note in this regard is that the SE Linux development process 
involves documenting what security critical apps do and allows review of them.  
There have been more than a few application/daemon security problems that 
allowed non-root compromises discovered by using SE Linux.

On Sun, 19 Jan 2014, Kevin Olbrich kolbr...@dolphin-it.de wrote:
 Even if there would not be a manipulated software package - hardware
 manipulation in mainboards or network hardware (like cisco does) is
 already known.

It is a documented fact that some government agencies can subvert hardware 
between the factory and the user.  However that is expensive and risky for 
them so would only be done on high value targets.  Most people need to be 
concerned with the case where good hardware is delivered to them and is 
compromised later.  In that case hardware compromise (EG BIOS replacement) is 
something that would only happen if the OS was compromised first.  So we need 
to concern ourselves with OS security.

On Sun, 19 Jan 2014, Andreas Kuckartz a.kucka...@ping.de wrote:
 I proposed this Debian Release Goal:
 https://wiki.debian.org/ReleaseGoals/SELinux

Thanks.

On Mon, 20 Jan 2014, JKAbrams.se j...@jkabrams.se wrote:
 We can not refrain from drawing conclusions because of their
 implications, if they indeed are correct, that would be self
 deception. The answer to the question is: Yes, it is indeed possible
 that an organisation with the NSA's budget and determination could
 have compromised a component of Debian, or any other open source
 software. Has there been any evidence to suggest this is the case? No.
 At least, not yet. (Remember, the publishing of the leaks are not
 random, and Greenwald has signed up for the owner of Paypal.)
 The task we have been reluctantly assigned is enormous, but is 

Re: flashplugin-nonfree get-upstream-version.pl security concern

[Russell Coker]

On Thu, 13 Dec 2012, Moritz Mühlenhoff j...@inutil.org wrote:
 Plus, installing Flash opens the Pandora's box anyway

When a user runs a web browser that calls the Flash plugin then that user 
session is exposed to the risk of a compromised Adobe web site etc.  When the 
user visits a potentially hostile web site they are exposed to the risk of 
compromise via a potential bug in the Flash plugin.

But in all cases installing the package should not give a risk of root 
compromise.  If there is a path from installing the Flash plugin (or any other 
package that downloads files) to a root compromise that doesn't involve a 
kernel bug then it's a bug that needs to be fixed.

Admittedly most Linux workstations are single-user systems nowadays which 
means that a user compromise gives almost all the benefits to the attacker of a 
root compromise.  But even so vulnerability to user compromise is no reason to 
be less vigilant about a potential root compromise.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201212131013.54074.russ...@coker.com.au

Re: About audit2allow generated rules

[Russell Coker]

On Fri, 27 Apr 2012, Min Wang ser.ba...@gmail.com wrote:
 just wondering where is the tclass=sock_file defined?

In the refpolicy source it is in policy/flask/access_vectors .

basically i have apache mod_tile want to access
 
 /var/run/renderd/renderd.sock ( from renderd)
 
 ls -lZ /var/run/renderd/
 -rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0 renderd.pid
 srwxrwxrwx. apache apache system_u:object_r:var_run_t:s0   renderd.sock
 -rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0
 renderd.stats
 
  how can I change /define
 
 tclass=sock_file

sock_file is the class of the object, other classes include file and dir.  
These are not things you change, these are human readable names for things 
that are part of the OS.

What you want to do is to have the daemon run as renderd_t and use 
renderd_var_run_t as the type for the socket fike.

 what I want to do is  just granting the permission that is needed?
 or generally is there a simple way to how to define/write a policy
 that only give the needed permission ( there are some howto seems still
 complicated??) ?
 not just rely on  aduit2allow to do the magic blindly?

As I said before, you can just grant that access and and it will work.  But if 
the renderd is running as root then it is a security risk (I guess that 
renderd is running as initrc_t or unconfined_t and is not being restricted by 
SE Linux).  Even if renderd is not given excessive privs then it's not ideal 
to allow httpd_t access to sock_file:var_run_t due to the possibility of other 
daemons being able to create such objects.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201204271147.28959.russ...@coker.com.au

Re: About audit2allow generated rules

[Russell Coker]

On Thu, 26 Apr 2012, Min Wang ser.ba...@gmail.com wrote:
   I have something in /var/log/audit/audit.log like:
 
 avc:  denied  { write } for  pid=23739 comm=httpd name=renderd.sock
dev=dm-0 ino=1183752 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
 
 
 use audit2allow it generates something like this:
 
 allow httpd_t var_run_t:sock_file write;
 
 
 Is the rule too liberal? that means httpd_t can write any var_run_t 's
 sock_file?
 Or I miss-understand something?

Ideally there should be no sock_file objects with type var_run_t, every Unix 
domain socket should have a type which is derived from the domain of the 
process which creates it.  So having one such socket is an indication of your 
configuration not being ideal.  If you only have one daemon with policy that 
allows such sockets then it's probably not a big deal to grant access to 
httpd_t.

Think of var_run_t being similar to the nobody UID in this case.  Having 
exactly one daemon running as nobody theoretically isn't a security problem, 
but having two daemons running with that UID probably is.  The problem is that 
people tend not to stop at one, if they have one daemon running in that manner 
then they may end up with two (through a repeat of the same choices) - so it's 
best to stick with zero!

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201204261400.32369.russ...@coker.com.au

Re: Security Implications of DKMS?

[Russell Coker]

On Tue, 27 Mar 2012, David Ehle e...@phys.iit.edu wrote:
 Isn't having compilers/build tools considered a security no no if 
 possible to avoid?

There have been some attacks on systems which have relied on the presence of 
various compilers and interpreters, the best known example is the Morris Worm.  
But there are few of them that couldn't have been written to talk to a server 
which has binaries for all common platforms and download the code that 
matches.

Nowadays there are far fewer platforms than there used to be so any hostile 
party who develops an exploit for Linux will probably just concentrate on i386 
and AMD64 with a somewhat recent GLIBC.

Also there's the issue of how a system is exploited.  If an exploit relies on 
a bug that is specific to a particular architecture of a particular OS then 
there would be no benefit in the attacker sending source code as they know 
exactly the binary that they need to send.

Finally there's a lot that can be done with Perl, Python, and shell scripts 
and a modern Debian system is not very usable without all three of those.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201203271914.29174.russ...@coker.com.au

Re: Dedicated server vs. VPS

[Russell Coker]

On Mon, 5 Mar 2012, Stayvoid stayv...@gmail.com wrote:
 Which one is more secure?

The one that is run by the most skilled people who devote the most resources 
to making it secure.

But this is nothing to do with the debian-security list.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201203051035.18279.russ...@coker.com.au

Re: OpenSSH not logging denied public keys, even with logging set to verbose.

[Russell Coker]

On Fri, 2 Mar 2012, Jordon Bedwell envyge...@gmail.com wrote:
  Run the command below.
  
   grep ssh:1.%.30s@%.128s.s password: /usr/sbin/sshd; echo $?
  
  If you don't get 1 as output, your sshd is compromised.
 
 It returned 1, this happens on freshly installed Debian and Ubuntu too
 though, tested it on Ubuntu too.

http://etbe.coker.com.au/2011/12/31/server-cracked/

If you havd a sshd that is compromised in the same way as one was on one of my 
servers then Anibal's command will give an output of 0.

I don't know what relevance this has to a discussion of OpenSSH logging 
though.

I'd like to have OpenSSH log the email address field from a key that was used 
for login so I could see something like ssh key russ...@coker.com.au was used 
to login to account rjc in my logs.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201203021157.47219.russ...@coker.com.au

Re: OpenSSH not logging denied public keys, even with logging set to verbose.

[Russell Coker]

On Fri, 2 Mar 2012, Mike Mestnik che...@mikemestnik.net wrote:
  I'd like to have OpenSSH log the email address field from a key that was
  used  for login so I could see something like ssh key
  russ...@coker.com.au was used to login to account rjc in my logs.
 
 From what I know that information(the comment on the key) is not vary
 secure, Joe could put Bob as his comment...
 
 However one could so a look-up on the key from a key-server and get the
 email address that way.  This is assuming that ppl are using there
 gpg(email) keys for ssh.

As the person who edits ~/.ssh/authorized_keys can put whatever they like in 
that field the value isn't great globally.  But in the scope of the one 
account it matters.  For example if your account was compromised via a ssh 
authentication and you had three public keys listed it would be really 
convenient to know which of the three was used.  While the second hostile 
login couldn't have any useful logging data if my suggestion was followed the 
first would.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201203021348.00806.russ...@coker.com.au

Re: how to fix rootkit?

[Russell Coker]

On Thu, 9 Feb 2012, Milan P. Stanic m...@arvanta.net wrote:
 On Wed, 2012-02-08 at 17:56, Fernando Mercês wrote:
  I think you're talking about syscall interceptions and related stuff.
  You're right, we can't trust, but it in this case we're talking about
  a very specialized malware and I don't see any fast action to bypass
  it. Maybe the conclusion is that we can't trust anything, so we can't
  do anything, but something need to be done, right?
  
  An option is load another kernel with kexec but we can't trust kexec.
  What we do?
 
 What about device which can be tapped to the CPU of running machine and
 then 'take over' CPU. Such device could then read RAM, block devices and
 peripherals to save data for post mortem analysis.

There are devices which use firewire to directly access system RAM.  It is 
also possible to design a PCI/PCIe card which does bus-mastering on external 
control to dump RAM contents.  I've seen a live demonstration of the use of 
firewire to directly access system RAM, a system was compromised by having 
some memory altered, dumping the RAM would be trivial by comparison.

It has also been demonstrated that if you chill RAM to a low temperature then 
you can extract it from the system with most of it's contents intact.

But these aren't things that you start thinking of after you have a 
compromised system, most desktop systems and servers don't have firewire and 
almost no systems have a PCI/PCIe card to dump RAM.  Using dry-ice or liquid 
nitrogen on RAM isn't something that you would do without some planning 
either.

 Although some secret agencies could already have something like that
 I'm not sure that it is commercially available or it will in the near
 future.

There are some people who would provide such things for the right money.

 If someone think that hardware manufacturer could design and put on the
 market computers with such option built in, I suspect that it will be
 suppressed by legislator.

No, it would be suppressed by the people who want to save every last cent on 
manufacture.  Anything that isn't the cheapest way of designing a system is 
going to be a really expensive optional extra.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202092319.45519.russ...@coker.com.au

Re: how to fix rootkit?

[Russell Coker]

On Thu, 9 Feb 2012, Stephen Hemminger shemmin...@vyatta.com wrote:
 The advice I heard is trust nothing (even reflash the BIOS).

Do you know of any real-world exploits that involve replacing the BIOS?  It's 
been theoretically possible for a long time but I haven't seen any references 
to it being done.

Also one thing to keep in mind is the apparent competence of the attackers.  
If they didn't bother changing debsums then it's unlikely that they did any of 
the other tricky things which have been discussed (such as trojaning the 
kernel).

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202091107.20847.russ...@coker.com.au

Re: how to fix rootkit?

[Russell Coker]

On Thu, 9 Feb 2012, Jason Fergus le...@thefnords.org wrote:
 Out of curiosity, couldn't one technically boot up a liveCD, mount the
 drive(s) and then download the .debs individually, then extract them
 over the mounted partitions, effectively copying over all of the
 binaries.

There is the possibility of SUID binaries not owned by packages and the issue 
of configuration files which have malicious changes.

The best thing to do is to install all the same packages on a new system and 
then run a diff -r on the /etc directory and determine which differences are 
desired configuration changes and which might have been made by the attacker.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202091529.38623.russ...@coker.com.au

Re: Bug#605090: Linux 3.2 in wheezy

[Russell Coker]

On Fri, 3 Feb 2012, Christoph Anton Mitterer cales...@scientia.net wrote:
 Wasn't it once the case with PaX that packages have to be compiled
 specially? Or some ELF headers added or so?

Some shared libraries have code which can't be run without an executable 
stack, it's a small number of libraries that are written in assembler code.  
We want to allow running them but don't want to give all programs permission 
to execute code on the stack.

From memory the GR Security option for this was to flag the rare executables 
that want an executable stack and are permitted to have it.

The solution devised by libc/gcc upstream was to have a special assembly 
section in every shared object that doesn't require an executable stack and if 
an executable only loads shared objects that don't require it then the 
executable stack is disabled.  Then we have SE Linux policy to prevent most 
programs from having an executable stack which means that if they are tricked 
into loading some of the rare libraries that need it then it doesn't do 
anything bad.

The downside to the latter approach is that lots of shared objects which have 
some assembler code needed to be patched.

The PaX approach involved less work.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202031215.27866.russ...@coker.com.au

Re: SELinux on Squeeze?

[Russell Coker]

On Sat, 31 Dec 2011, Holger Levsen hol...@layer-acht.org wrote:
 On Freitag, 30. Dezember 2011, Russell Coker wrote:
  I can't imagine what the benefit would be in using official packages
  that I created and uploaded to Debian over using unofficial packages
  that I created and couldn't get in a Squeeze update
 
 Frankly, your lack of imagination is pretty sad. The difference is that
 people cannot use squeeze properly without relying on some external
 repository.

They can if they are satisfied with the features that were in Squeeze.  But we 
have lots of other repositories for people who want more, for two random 
examples there's debian-mm for people who want codecs that aren't in Squeeze 
for legal reasons and backports.

Another feature of my repository is that I include some packages built with 
features that aren't liked by the DD who maintains them.  Such as ffmpeg 
packages that don't need execmod permission on i386.  This makes it a little 
slower but means that it will be more difficult for someone to attack your 
system with a hostile movie file.

There are many DDs who maintain their own repositories with more features than 
is in Stable.

 Imagine if every DD would handle her packages like this.

Not everyone does it, but many do and it's better for users.

 Releases (as in Debian stable releases) would be rather useless.

No, you have the stable packages for things that you don't care much about and 
use newer versions for things that are important to you.

 Maybe this can be finally fixed for wheezy?

The only way that could be fixed is if I was to stop development after 
Wheezy is released.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112312226.49349.russ...@coker.com.au

Re: SELinux on Squeeze?

[Russell Coker]

On Sat, 31 Dec 2011, Laurentiu Pancescu lpance...@googlemail.com wrote:
 effective). I tested Exec-shield in Debian a few years ago, with and 
 without SELinux, it makes a big difference:

I just did a quick test on an i386 system with PAE running a 686 Squeeze 
kernel.

SE Linux enforcing vs permissive made no difference to paxtest results with a 
default configuration.  But when I was in enforcing mode and defined an 
account with user_t as the default domain (instead of unconfined_t) the test 
Writable text segments was no longer reported as vulnerable.

 I think now only grsecurity is available in Debian, providing similar
 functionality (it does much more than exec-shield, but it's also more
 intrusive - not sure if it's even possible to use SELinux at the same
 time). I don't mean this in a bad way, grsecurity seems to boost kernel
 security quite a bit:

The Gentoo guys integrated PAX and SE Linux.  When you think of non-exec stack 
and GRSecurity you are thinking of PAX.

 http://labs.mwrinfosecurity.com/notices/assessing_the_tux_strength_part_2_i
 nto_the_kernel/

Interesting article, it doesn't make Debian look good.  :(

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112312300.20562.russ...@coker.com.au

Re: SELinux on Squeeze?

[Russell Coker]

On Fri, 30 Dec 2011, Laurentiu Pancescu lpance...@googlemail.com wrote:
 I would like to harden a web server setup using SELinux. How good is the
 support for SELinux on Squeeze? Are the instructions on the Debian Wiki
 [1] up to date for Squeeze? I tried this last time on Lenny, and DHCP
 couldn't work back then due to SELinux not letting modprobe load
 additional modules.

The support is quite good.  I run a bunch of Squeeze servers with SE Linux.

As for Lenny, I expect if you added appropriate entries to /etc/modules or 
used audit2allow you would have got it working.

 I'll only need Postfix, OpenSSH and nginx (or Cherokee - just static
 content for now). Are the official policy packages from Squeeze enough
 for such a setup, or should I always use Russel's repository? I had the
 impression Russel's changes are rather needed for a desktop, with fixes
 for mplayer and similar packages (I prefer using only official Debian
 packages, unless forced otherwise).

I can't imagine what the benefit would be in using official packages that I 
created and uploaded to Debian over using unofficial packages that I created 
and couldn't get in a Squeeze update because the changes would be too great or 
I didn't get time to go through the process of applying for them to be put in 
an update.

You will need to label those web server binaries as httpd_exec_t, use 
semanage fcontext -a to prevent a restorecon operation from undoing such 
changes.  Also you might need to generate some extra policy with audit2allow 
if they happen to do something different to Apache.  But the potential policy 
changes should be quite small, there really isn't much that Apache doesn't do.  
In many ways Apache could be regarded as the most complex daemon that we 
support in Debian.  According to SE Linux policy the MTAs are the only 
competition for that.

I have made more than a few changes to my unofficial policy packages that 
are specific to server operation, one that I recall is better support for 
NAGIOS.

 P.S. Russell, if you are reading this, lots and lots of thanks for the
 years of work on SELinux under Debian - I think we would have probably
 never got SELinux on Debian without your efforts.

I'm glad you appreciate it.

Debian was the first distribution to support SE Linux.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112310015.30479.russ...@coker.com.au

Re: SELinux on Squeeze?

[Russell Coker]

On Sat, 31 Dec 2011, Laurentiu Pancescu lpance...@googlemail.com wrote:
 is there any difference between i386 and amd64 as to how much protection
 SELinux is able to provide? Earlier, stuff like NX was only available on
 64-bit processors; are there still such differences?

There has never been any difference in SE Linux support between those 
architectures AFAIK.

Support for NX etc is a kernel/hardware issue.  AMD64 hardware is more capable 
in this regard but there are kernel patches to provide similar things for 
i386.  I'm not sure of the status of this in Debian.

  As for Lenny, I expect if you added appropriate entries to /etc/modules
  or used audit2allow you would have got it working.
 
 It didn't occur to me to add anything to /etc/modules, but I did try to
 add the rules suggested by audit2allow. It compiled the policy, I added
 it, but it still didn't work - I probably did something wrong (I had
 only read the wiki page before and skimmed through the Fedora 5 SELinux
 FAQ). I gave up after a day or so, it was my only system and couldn't
 work. I should have read more before jumping in - mea culpa. Is there
 any other documentation about SELinux except the one linked from the
 wiki, your blog and the NSA paper? Do any Debian administration books
 address SELinux?

I am not aware of Debian books covering SE Linux.  But Red Hat has some good 
documentation and most of it will apply to Debian.

  I can't imagine what the benefit would be in using official packages
  that I created and uploaded to Debian over using unofficial packages
  that I created and couldn't get in a Squeeze update because the changes
  would be too great or I didn't get time to go through the process of
  applying for them to be put in an update.
 
 Well, your post a few hours ago about getting hacked (in taz's thread)
 scared me into thinking that the official packages might be safer... :)
 OTOH, I know you used to have a public SELinux server with root access
 for anyone to try, so I guess it can't be _that_ bad.

http://etbe.coker.com.au/2011/12/31/server-cracked/

I've just written about that at the above URL.  As I note in that post I count 
that as a win for SE Linux.

 I remember first considering SELinux after the hacking of a few Debian
 servers some years ago; the post-mortem analysis mentioned that SELinux
 would have prevented it and recommended enabling it if possible (was it
 Wouter's blog?). I also remember Manoj fought quite hard to get SELinux
 included by default in Debian, but many developers opposed it being
 active by default, like in Fedora. Too bad.

From memory that was an exploit of a race condition involving kernel module 
loading.  The access that triggered the module loading was denied by SE Linux 
and therefore it didn't work.  The attacker could potentially have written an 
exploit that triggered a module load without being stopped by SE Linux, but it 
would have been a little harder and probably wouldn't have worked on as many 
systems.

But generally if you want to prevent random (as opposed to targetted) attacks 
then anything you do to make your system more difficult than the majority will 
do some good.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112311255.48278.russ...@coker.com.au

Re: need help with openssh attack

[Russell Coker]

On Fri, 30 Dec 2011, Taz taz.ins...@gmail.com wrote:
 of course, i've double changed all password and regenerated ssh keys.

Are the SSH and PAM settings doing what you think?  I suggest carefully 
examining the contents of /etc to see what has been changed from the default.

A new sshd vulnerability that allows remote access would be worth a lot of 
money, it would initially only be used on the most important systems and 
people who use it would be careful not to reveal what they have.  When an 
exploit that is used by attackers becomes known and gets fixed the people who 
were using it lose money.

If there was a hole in sshd would your server be important enough to justify 
the risk?  Also would they use and risk a valuable sshd exploit on a mere 
spam-bot?

http://etbe.coker.com.au/2011/12/31/server-cracked/

As an aside, the above blog post has information on how one of my servers was 
cracked.  It could be the same way that yours was.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112311314.38787.russ...@coker.com.au

Re: need help with openssh attack

[Russell Coker]

On Fri, 30 Dec 2011, Taz taz.ins...@gmail.com wrote:
 Hello, we've got various debian servers, about 15, with different
 versions. All of them have been attacked today and granted root
 access.
 Can anybody help? We can give ssh access to attacked machine, it seems
 to be serious ssh vulnerability.

http://blog.sesse.net/blog/tech/2011-11-15-21-44_ebury_a_new_ssh_trojan.html

The above blog post may be of use to you.  One of my servers was compromised 
via that one.

 How can i contact openssh mnt?

Colin Watson cjwat...@debian.org

The changelog for the openssh-server package gives Colin as the maintainer.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112300138.11707.russ...@coker.com.au

Re: Fwd: Problem with multiple root-users (UID=0)

[Russell Coker]

On Wed, 16 Nov 2011, Ritesh Raj Sarraf r...@debian.org wrote:
 On 11/16/2011 11:15 AM, Mike Christie wrote:
  Hey Ritesh,
  
  Does Debian have some sort of security list? I asked some red hat people
  and they thought removing the check for root and just checking for
  UID=0 would be ok. They were not 100% sure though since we could not
  figure out why the original maintainers check explicitly for root. So I
  have been checking with distro people to make sure it is ok with their
  security people.
  
  Thanks
  
  Mike
  
  
  
  
   Original Message 
  Subject: Problem with multiple root-users (UID=0)
  Date: Mon, 7 Nov 2011 11:37:29 -0800 (PST)
  From: Thomas Weichert tho...@weichert-web.de
  Reply-To: open-is...@googlegroups.com
  To: open-iscsi open-is...@googlegroups.com
  
  Hi,
  
  in the last few days I encountered a problem on my SLES 11.1 Linux
  with the open-iscsi package in version 2.0-871 respectively 0.872. I
  investigated the problem and found out that in my system there are two
  root users with uid = 0 (sadly, this is required). Therefore I digged
  deeper and found out that the problem most probably lies in the two
  code snippets where root is defnied explicitely. Those are usr/
  mgmt_ipc.c around line 549 with:
  
  if (!mgmt_peeruser(fd, user) || strncmp(user, root, PEERUSER_MAX)) {
  
  err = MGMT_IPC_ERR_ACCESS;
  goto err;
  
  }
  
  as well as usr/statics.c around line 7:
  
  static struct passwd root_pw = {
  
  .pw_name = root,
  
  }
  
  When the Linux command `whoami` returns something different than
  root, open-iscsi will not work.
  
  As far as I understand the issue, the function call to mgmt_peeruser()
  in mgmt_ipc.c sets the variable user to the currently logged in user
  name and then it is compared to root.

From a casual examination of the code it appears that the UID of the other end 
of the Unix domain socket connection with file handle fd is looked up via 
getpwuid() and then compared to root.  So the only way we determine that the 
other end has permission to do whatever it wants is that it's UID maps to the 
name root, which generally means UID==0.

As long as the UID==0 account named something other than root appears later 
in /etc/passwd this should work as you desire.

Of course just allowing UID==0 to do sysadmin stuff isn't a great idea.  SE 
Linux is one of several security systems that give you processes with UID==0 
but significantly less privileges.  Any time you have code which ONLY checks 
for UID==0 you potentially have something that could be used as part of an 
exploit on a SE Linux system - although in such a case it would be an exploit 
on every system that only uses Unix permissions anyway.

It appears that the abstract socket namespace as described in unix(7) is being 
used, this doesn't use a path name and apparently uses no other security 
mechanisms.  Therefore I expect that if someone exploited a root owned process 
that is constrained by SE Linux or another security system then if it was 
permitted to establish Unix domain socket connections it could mess with your 
iscsi.

  If my root-user is named
  differently, the strncmp function fails of course. I did not
  investigate the code in statics.c further, whether it plays a role or
  not, since a change to mgmt_ipc.c solves my problem.

statics.c seems like a bad idea.  Replacing a libc function with something 
that provides a tiny sub-set of the functionality which is hard-coded in a way 
that may not match the rest of the system seems like a really bad idea.

  Is there a chance to fix this issue just by checking if the user has
  sufficient rights, e.g. has uid=0, or is there any special reason for
  demanding a user named root?

Checking for uid==0 would be better than statics.c.  Also checking for uid==0 
would avoid potential threading issues (of course they could use 
getpwuid_r()).

But really something better than assuming that every uid==0 process has 
ultimate privilege is the way to go.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20161929.49953.russ...@coker.com.au

Re: [SELinux] Wildcard for object classes?

[Russell Coker]

On Sat, 29 Jan 2011, Simon Brandmair sbrandm...@gmx.net wrote:
 I just started looking into SELinux. I am wondering if there is a way to
 have wildcards in avc rules like:
 auditallow source_t target_t : * * ;
 which audits all access from source_t to target_t.
 
 Or do I have to add all classes objects to the rule like:
 auditallow source_t target_t : {appletalk_socket, association,
 blk_file ... } * ;

No, there isn't such a wildcard at this time (AFAIK).  It might be worth 
adding one so I've moved this discussion to the SE Linux upstream mailing list 
(please don't CC debian-security on future replies).

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103061032.21143.russ...@coker.com.au

mitacs.com is a spam domain - configure your mail server to block it

[Russell Coker]

Every message that you send to supp...@mitacs.com will be resent to debian-
security.  Every message you send to postmaster or abuse will be ignored.

Please everyone, configure your mail servers to block all mail from 
85.125.218.18 and all mail with @mitacs.com in the From: field.

If you really want to be sure that you don't get a recurrence and if your mail 
server does DNS checks or callouts then block port 53 traffic to/from 
85.125.218.15 and 213.235.249.3 (the mitacs.com DNS servers).  Alternately you 
could configure your recursive DNS server to have a mitacs.com zone with an 
SPF record that permits mail from no-one or a DKIM ADSP record that requires 
signed mail.

mitacs.com should not be on the Internet.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007141935.03325.russ...@coker.com.au

Re: Creating my own personal Linux distribution for Penetration Testing and White-Hat Hacking

[Russell Coker]

On Monday 08 December 2008 21:40, Tom Allison [EMAIL PROTECTED] wrote:
 Is there some means by which you can build a super set of packages as a
 package?  I think there is, but I'm not sure how it works.

 The idea would be to select a Package which would then select a large
 list of packages to install and others to make sure are removed and then
 move into a process of specialty configuration of those packages.

You can create a package that does nothing but depend on packages you want to 
have installed, and possibly conflict with packages you want removed.

I suggest however that in such a case you have one package which handles the 
conflicts and have the main meta-package recommend (not depend) on it.  Then 
if someone really wants to have one of the undesired packages then they can 
do it.

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: Creating my own personal Linux distribution for Penetration Testing and White-Hat Hacking

[Russell Coker]

On Sunday 07 December 2008 16:11, Reed Young [EMAIL PROTECTED] wrote:
 For any set of packages one finds so useful that they're like their own
 distribution, I think the labor would be better spent -- more useful to the
 community I mean, maybe not as fun for you -- in extending / improving
 documentation on using those tools, or Chip's suggestion, which looks to me
 like 'debianising.'  Your message indicates a comprehensive security
 strategy, and a large market for that certainly exists.  But the additional
 work of maintaining a separate distribution seems like a waste.

http://www.debian.org/misc/children-distros

One thing that probably should be considered is the fate of the Adamantix 
distribution.  The above URL seems to be the only current information 
available on the web about it.  It seems that the only current positive 
result from that project is the paxtest package which is in Debian (which 
incidentally is i386 specific).  I expect that the same amount of effort 
could have yielded better results if applied within the scope of Debian.

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: Creating my own personal Linux distribution for Penetration Testing and White-Hat Hacking

[Russell Coker]

On Monday 01 December 2008 22:45, Chip Panarchy [EMAIL PROTECTED] 
wrote:
 My distribution has been specialised to suite the requirements of your
 everyday (and not so everyday!) pen-tester and white/grey hat hackers.

 My sobriquet for this distribution is: HackBuntu.

Why not just have a set of extra packages to run on Debian/Lenny?  Why is a 
different distribution needed for penetration testing?

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: Encrypt file while you are using it

[Russell Coker]

On Tuesday 25 November 2008 16:53, Rolf Kutz [EMAIL PROTECTED] wrote:
 Whenever you are able to read a file, it has to exist in unencrypted
 form. Let's say you have an editor or viewer that has builtin-in
 decryption. It will read the encrypted file, and decrypt it. to be able
 to work on it, the program has to keep the decrypted form. It also
 has to send it to some device for you to be able to work on it. The
 decrypted form will be readable from /dev/mem or /proc/pid/mem. by
 the superuser and (procfs only) your user. It will also be possible
 for at least the superuser to intercept what is going to the device.
 There is nothing you can do to prevent these kinds of attacks.

 You could use SELinux to prevent these kind of
 attacks.

http://etbe.coker.com.au/2008/11/25/se-linux-and-decrypted-data/

SE Linux can improve things, but it doesn't entirely solve the general problem 
presented here.  I have addressed this issue with the above blog post.

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: secure execution of drivers

[Russell Coker]

On Tuesday 25 November 2008 22:29, Aneurin Price [EMAIL PROTECTED] 
wrote:
 Based on my experience, I would not personally recommend XFS to anyone who
 cannot guarantee that their system will absolutely never crash or suffer
 power failure. XFS's failure modes seem pretty disastrous. Then again I
 never had any problems when I was using reiserfs, so YMMV.

One issue with XFS is that data which is not written synchronously (IE opened 
with O_DIRECT or O_SYNC) or explicitly synchronised with fsync() may stay in 
the write-back cache for up to 30 seconds (compared with 5 seconds for 
Ext2/3).

Now for correctly written applications that call fsync() when appropriate this 
should not be a problem.  But for buggy applications this can cause 
significant problems.

One example where this caused a disaster was a program that used the create 
and rename method of replacing a file.  It would often replace the file more 
than once in 30 seconds.  This meant that on XFS the main file and the backup 
could end up without any data blocks but on Ext3 as the period was 5 seconds 
it mostly worked.  Of course the program in question worked better on Ext3 as 
well once I put a fsync() call in the source...

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: Encrypting drive

[Russell Coker]

On Monday 02 July 2007 11:35, Anders Breindahl [EMAIL PROTECTED] wrote:
 In servers, you might want to trust physical security, since
 whole-system encryption incurs a performance degradation. (However, on a
 reasonably recent system, you still will be bottlenecked by Fast
 Ethernet at 100Mb/s).

Where reasonably fast means faster than a 3GHz P4.  A 3GHz P4 system I was 
working on recently appeared to be limited to 4MB/s, if it wasn't for the 
fact that the machine is about to be decommissioned then I would probably 
investigate this further as the performance is lower than expected.

 However, if you should choose to encrypt only, say /home, you'd need to
 make sure that data won't ``sieve'' onto the unencrypted parts of the
 system, such as /tmp or swap space.

True.  But the advantage to encrypting only some partitions is that you can 
get better performance for non-secret data.

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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

Re: Encrypting drive

[Russell Coker]

On Monday 09 July 2007 22:23, Anders Breindahl [EMAIL PROTECTED] wrote:
  Where reasonably fast means faster than a 3GHz P4.  A 3GHz P4 system I
  was working on recently appeared to be limited to 4MB/s, if it wasn't for
  the fact that the machine is about to be decommissioned then I would
  probably investigate this further as the performance is lower than
  expected.

 Funny. I get 4 MB/s of AES256 on an 850MHz P3. And 11MB/s on a 3500+
 AMD Sempron. And well above that when using VIA Padlock on another
 system.  Are you certain that you're not bottlenecked by some other
 problem?

Not certain, and the machine was being used for some processes other than the 
disk copy.  I may do some further tests after completely decommissioning it.

   However, if you should choose to encrypt only, say /home, you'd need to
   make sure that data won't ``sieve'' onto the unencrypted parts of the
   system, such as /tmp or swap space.
 
  True.  But the advantage to encrypting only some partitions is that you
  can get better performance for non-secret data.

 If you're stuck with 4MB/s as transfer speed, you could consider
 security trade-offs for performance. But in a faster scenario, I
 wouldn't opt for it.

I don't think that it's a security trade-off to have a file-system for ISOs of 
Linux distributions that is unencrypted (as an example of one of my 
machines) - unless the threat model includes an attacker sneaking in, 
modifying things, and then leaving without detection - a much harder problem 
to solve.

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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

Re: Security features of Debian Etch?

[Russell Coker]

On Sunday 27 May 2007 10:49, Németh Tamás [EMAIL PROTECTED] wrote:
 Does Debin Etch have some extra chroot
 restrictions, /dev/mem, /dev/kmem, /dev/port, /proc/PID/stat,
 /proc/PIDmaps, Linux privileged I/O related or other security
 enhancements beyond to the security of the vanilla Linux kernel?

The SE Linux support in Etch will address some of your requirements in this 
regard.

SE Linux is not based on chroot but on the domain of the program in 
question.  So a program can be run without chroot but still have great 
restrictions applied to it.

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

Re: Security Debian Questions

[Russell Coker]

On Sunday 22 April 2007 01:58, Jim Popovitch [EMAIL PROTECTED] wrote:
 On Fri, 2007-04-20 at 20:30 -0500, George P Boutwell wrote:
  I don't remember the exact details, but the problem I think revolved
  around not being able to properly boot-up since the /tmp and/or the
  /var/tmp where needed during the boot, but not being mounted yet.

 Actually in order for /tmp to even be mounted their needs to be a /tmp
 directory on the root filesystem.  Chances are, that it's not the lack
 of mounting /tmp, but rather the permissions of /tmp (mounted and/or
 unmounted).

The permissions of the mount point don't matter.  Mount runs as root with 
capability DAC_OVERRIDE so a mode 0 mount point will do fine.

If the mount-point doesn't exist or is not a directory then the mount 
operation will fail.

-- 
[EMAIL PROTECTED]
http://etbe.blogspot.com/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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

Re: Bug#357561: privilege escalation hole

[Russell Coker]

On Friday 02 March 2007 21:30, Bjørn Mork [EMAIL PROTECTED] wrote:
 Nor did I.  Does anyone have a pointer to a discussion of this?  I
 assume it must have been discussed a few times already.

A few times in other places, not sure about this list.

 I think I'll stop using su now ;-)

setsid su will be fine, as will exec su in some situations (where the call 
chain results in the termination of su closing the terminal).

 BTW, I noticed that mysql-server-5.0 also has a problem similar to
 apache.  This is the ps output after a recent apt-get upgrade:

 root  8458  0.0  0.0   3912   904 pts/3SFeb28   0:00 /bin/sh
 /usr/bin/mysqld_safe mysql 8495  0.0  0.3 126524  3780 pts/3Sl  
 Feb28   0:00  \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
 --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --ski root  8496 
 0.0  0.0   2968   356 pts/3SFeb28   0:00  \_ logger -p daemon.err
 -t mysqld_safe -i -t mysqld

It's hard to tell.  The parent process didn't call setsid(), it would probably 
be best if mysqld_safe would call setsid() before executing the mysqld.  But 
if mysqld called setsid() then it would not be exploitable.

 Does the special treating of terminal exploits mean that this is not a
 bug?  Or should it be reported with a low severity?  As opposed to
 apache, normal users rarely have access to run their own code in mysql
 context anyway, so exploitng this may be difficult.

If a user cracks the mysqld then they may be able to take over the root 
account because of this.  I believe that it's something that we should get 
fixed.  Using setsid(8) to run mysqld would fix it.

The mysqld is started as root and then changes it's UID to mysql, this means 
that it can not be ptraced (in a default kernel configuration) which makes it 
slightly more difficult to exploit this apparent bug.

Also in a default Debian install there is no password for the root account 
in the MySQL users table (see the following for an example).  I've just filed 
a bug report against mysql-server.

$ echo select Host,User,Password from user where Grant_priv='y' | mysql -u 
root mysql
HostUserPassword
localhost   root
aeonroot
localhost   debian-sys-maint*882F

-- 
[EMAIL PROTECTED]
http://etbe.blogspot.com/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

Re: /dev/log

[Russell Coker]

On Wednesday 06 July 2005 05:05, Ian Eure [EMAIL PROTECTED] wrote:
 It's used by syslogd. Not 100% sure on this, but I believe it's how
 user-space apps send messages to syslog (e.g. with syslog(3)). If that's
 the case, it would need to be mode 666 for syslog(3) to work.

It doesn't have to be mode 0666, it just needs to be writable by every program 
that you want to log via syslog.  As there are many daemons which run as 
non-root (most daemons should not have root privs) and there is no group for 
daemons to allow such access it's almost required to grant every process 
access to /dev/log.

If you want restricted access to /dev/log then you need something more capable 
than regular Unix access control.  POSIX ACLs could do the job, but you would 
have to patch the syslogd to set the ACLs every time it starts up.  If you 
run SE Linux then /dev/log access is controlled and you can determine which 
programs get access to it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: FIle access auditing

[Russell Coker]

On Wednesday 27 April 2005 21:16, Marcell Metzner [EMAIL PROTECTED] 
wrote:
 I have seen this using SE Linux or RSBAC.
 This 2 are the best I have seen till now.

One limitation of SE Linux in this regard is due to the design of the LSM 
interface.

The LSM interface does not get called until after Unix permissions have been 
checked.  So for example if I have a process running as UID!=0 and 
group!=shadow which attempts to read /etc/shadow then that operation will not 
be audited by SE Linux.

RSBAC is not based on LSM and is not subject to that limitation, so it may be 
able to audit such things.

However there is code in the standard kernel.org 2.6.x kernels to do this, you 
need the auditctl and auditd programs and the following options in your 
kernel config:
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Compromised system - still ok?

[Russell Coker]

On Monday 07 February 2005 14:43, Alvin Oga [EMAIL PROTECTED] 
wrote:
  No, you make an image, reinstall, and if you  have time (ie. you normally
  dont) then you can start the forensics.

 yes about making an image ... i assume you mean
  - take the box down,
   - i hate taking the box down, as you can lose
   valuable info in its memory

Unless you have special hardware installed it's impossible to take a memory 
image of a running machine.  There are PCI cards available which use 
bus-mastering to copy the memory of a live machine for forensics, but they 
are expensive and would have to be installed before the machine was cracked.

Inspecting the memory of a running machine that has been properly cracked is a 
problem as it may be obscured by a kernel module.

Most people recommend abruptly cutting the power to a machine that may have 
been compromised.  That prevents unlinking files that have no links but which 
were in use at the time.  A shutdown process will give a consistent file 
system (losing data from temporary files) and may also lose other data.

  - i'd re-install into a new disk and leave the cracked one alone
  ( disks are super cheap )
   - i would not reinstall on the cracked disk
   as it can have hidden filesystems

How would hidden filesystems work?

Some name-brand machines (particularly laptops) have a BIOS extension stored 
on an IDE hard disk which apparently has some reserved disk space.  It seems 
that my Thinkpad had something like this, but now that I'm running 2.6.10 
Linux sees all the disk space which would allow me to increase my Linux use 
by 3.4G which would overwrite the Thinkpad stuff.  Once Linux is using all 
the space there's no-where to hide.

Assuming that you use all your disk space then hidden file systems shouldn't 
be an issue.

However it may be good to keep the disk anyway for evidence purposes.  Data on 
original disk may be better regarded than data on a DVD if the case ever 
comes to court.

  - for forensics.. use a good cd or build a custom disk
  with with lot of fun forensics on it and fiddle till one finds
  all the answers :-0

Make sure that you don't do forensics on the original image.  Investigating 
the situation may require running fsck etc which changes things.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: SELinux in debian/sarge

[Russell Coker]

On Monday 24 January 2005 19:10, Markus Schabel [EMAIL PROTECTED] 
wrote:
 I've setup a server with selinux enabled, using the packages from Russel
 Coker (http://www.coker.com.au/selinux/) but they are a bit outdated, at
 least there are more current packages in debian/testing available
 (coreutils, dpkg, dselect, initscripts, sysv-rc, sysvinit). I think the
 packages in sarge are not SE-enabled? Are there newer/current packages
 somewhere around (didn't find anything on apt-get.org and google)?

dselect, initsctips, and sysv-rc don't matter.  I will put new versions of 
dpkg and sysvinit on my site soon.  Some other people are working on 
coreutils.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Security issue? Daemon users has to much rights...

[Russell Coker]

On Sun, 24 Oct 2004 19:24, Jan Lhr [EMAIL PROTECTED] wrote:
  Yes, and that is one of the core points in my suggestion that you look
  at SELinux or a similar mandatory access control based security module.

 SELinux is overkill in some ways. A system adminstrator, not being able to
 handle ACLs won't be able to handle SELinux.

One of the problems with managing Unix access control is that there is no way 
of analysing the chain of operations.

Program A can execute program B which is SETGID, which then gives it access to 
execute program C which is SETUID (but not executable by the original GID), 
etc.  Analysing this would require an operation equivalent to find / to get 
the data and a tool which no-one has bothered writing to analyse it.

The SE Linux policy has an analysis tool which can follow chains of execution.  
If you are concerned about programs that can read /etc/shadow then you can 
search the policy to get a list of the domains that are permitted access to 
shadow_t.  Then you can get a list of types that are entry-points for those 
domains (EG the domain passwd_t has { read write } access to shadow_t and can 
be entered through type passwd_exec_t) and check which files are labelled 
with that type.  The code in those programs can then be audited for correct 
operation.  Also the number of domains which can execute passwd_exec_t files 
to enter the passwd_t domain is a small sub-set of the domains in the system.

The Unix permission system is very difficult to manage, and many security 
problems have occurred because of mistakes, misunderstandings, and oversights 
in manipulating it.  Posix ACLs make things worse by having all the features 
of Unix permissions plus more complexity.  SE Linux is far easier to manage 
correctly.  Unix permissions are much easier to manage, this can be 
considered a good thing (ease of use) or a bad thing (ease of borking a 
system).


The problems which started this discussion are all already solved with the 
default SE Linux policy.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: arp table overflow due to windows worm

[Russell Coker]

On Mon, 18 Oct 2004 07:08, Rick Moen [EMAIL PROTECTED] wrote:
 Quoting Jason Lunz ([EMAIL PROTECTED]):
  The entire neighbor cache was completely rewritten recently, and I
  believe it was prompted by exactly this sort of situation.

 Just wanted to mention:  That neigbour table overflow error can also
 be caused by inadvertantly removing the localhost line from one's
 /etc/hosts file, with the result that an avalanche of local socket
 requests clobber the system's ARP cache.

How does that work?  Connections to 127.0.0.0/8 go to device lo unless your 
routing table is broken.

Lookups on localhost with gethostbyname() should be expected to fail if 
there is no entry in /etc/hosts unless your default DNS search name has a 
localhost entry (in which case you have an entirely different set of 
problems).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Debian Hardened project status.

[Russell Coker]

On Mon, 27 Sep 2004 00:39, Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] 
wrote:
  Most of the features you list are things that are difficult to get into
  Debian/main.

 Not too really difficult, it depends on how it gets developed:
 http://www.debian-hardened.org/wiki/index.php/CVS_Development_Organization

 SSP and PIE don't affect the binaries performance (not seriously), and
 arbitrary patches get tested before using them. It goes under the lead210
 pool before it goes to system-dh.

These things are obviously difficult due to the amount of time that has been 
spent on them without anything getting into main.

The last discussion of SSP resulted in the GCC package maintainers indicating 
that they wanted to wait for Mudflap, other discussion indicates that Mudflap 
won't do what we really want in regard to such things (more of a debugging 
tool than a method of securing production code).  So I guess SSP is on hold 
until after Mudflap.

   About the kernels...the work is in production state, i've currently
   tested them on some machines , 2 of them are shared environments
   (software-libre.org  ourproject.org) with user chroots, etc.
   I've also did the DHKP, but i'm going to remix it and use instead of
   the current patches (OW and others) the PaX + RSBAC + SELinux mix.
 
  You have RSBAC and SE Linux in the same kernel?  What's the point?

 I haven't done that work, we are just starting to decided what's the
 painless solution.

Best thing to do is to have separate kernels for GRSEC, RSBAC, and SE Linux.

I am happy to test out all the SE Linux kernels you produce and review all 
code and configuration that you use.  Let me know when you are ready for me 
to do this.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Debian Hardened project status.

[Russell Coker]

On Sun, 26 Sep 2004 07:22, Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] 
wrote:
 - openssh (i'm working on the patches that bring SecurID Token use
 features, and others from independent hackers)

Most of the features you list are things that are difficult to get into 
Debian/main.  But token based security for openssh is something that seems 
like it could go in without too much pain.  Have you talked to Matthew Vernon 
about this?

 About the kernels...the work is in production state, i've currently
 tested them on some machines , 2 of them are shared environments
 (software-libre.org  ourproject.org) with user chroots, etc.
 I've also did the DHKP, but i'm going to remix it and use instead of the
 current patches (OW and others) the PaX + RSBAC + SELinux mix.

You have RSBAC and SE Linux in the same kernel?  What's the point?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Rebuilding packages on *all* architectures

[Russell Coker]

On Mon, 20 Sep 2004 06:15, martin f krafft [EMAIL PROTECTED] wrote:
 I want to add another point to this discussion. While we cannot
 prevent malicious maintainers from installing to the archives or
 poisoning the buildds, requiring all binaries to be remade on the
 buildds would rule out the possibility that an trojaned maintainer's
 machine would cause infected software to be distributed in the
 archives.

 Security it not absolute. But requiring all architectures to be
 rebuilt does add a significant amount of security, IMHO.

Requiring all packages to be rebuilt will prevent the binary from not matching 
the source.

But what if the source is modified?  Taking over a DD's machine and modifying 
the source tree that is used to make the .diff.gz shouldn't be impossible.  
We don't have any source auditing processes that could deal with this.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: apt 0.6 and how it does *not* solve the problem

[Russell Coker]

On Mon, 23 Aug 2004 13:30, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
 Russell Coker [EMAIL PROTECTED] writes:
  Removing from active status seems appropriate to me.

 But that's a totally different subject.  If you want to remove Debian
 developers from the list of developers, because they haven't uploaded
 in six months (what about packages that don't have bugs?!) then that's
 a different topic.  Please don't tie it to the security thing, which
 doesn't require removing them as developers.

Which is why I haven't suggested removing them entirely, just removing their 
active status (and therefore rights to upload packages, login to Debian 
servers, etc).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: apt 0.6 and how it does *not* solve the problem

[Russell Coker]

On Mon, 23 Aug 2004 09:34, Geoff [EMAIL PROTECTED] wrote:
 There is an elaborate system to maintain quality in new Debian
 developers (which seems like a good idea to me). Why not have some sort
 of system for ensuring the quality in continuing DD?
 If a DD didn't meet the criteria they would go into an inactive list,
 and if they stayed in the inactive list for 3 months, would go into the
 retired list, and their gpg keys _somehow_ invalidated. Is it possible
 on a gpg key server to mark a key as invalid, with out access to the
 private key?

Sounds like a reasonable idea.  We can't automatically make the key invalid.  
But we can have a central Debian key that's used to sign the keys of all 
developers.  If such a signature was revoked then it would show the change in 
status of the developer.

Removing developers who don't meet certain criteria (EG no package uploads for 
6 months) from active status makes a lot of sense.  Anyone care to propose a 
GR?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: apt 0.6 and how it does *not* solve the problem

[Russell Coker]

On Mon, 23 Aug 2004 13:07, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
 Russell Coker [EMAIL PROTECTED] writes:
  Removing developers who don't meet certain criteria (EG no package
  uploads for 6 months) from active status makes a lot of sense.
  Anyone care to propose a GR?

 Careful about terminology here.  I wouldn't say remove, just we drop
 them from the list of signatures.  They are still Debian developers.

Removing from active status seems appropriate to me.

If we are afraid of compromised packages then we can't have an automated 
method of changing status back to active.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: apt 0.6 and how it does *not* solve the problem

[Russell Coker]

On Mon, 23 Aug 2004 14:46, Bron Gondwana [EMAIL PROTECTED] wrote:
  Removing developers who don't meet certain criteria (EG no package
  uploads for 6 months) from active status makes a lot of sense.  Anyone
  care to propose a GR?

 This doesn't work.  The problem is basically:

 a) what about a package which they uploaded while valid, more than 6 months
 ago, that someone wants to download and install now.

That package doesn't matter, if they don't have active status then the Debian 
server machines won't accept it.

 b) if by date, what's to stop someone backdating a package and falsifying a
mirror/proxy with a copy of their package.  The signature will still
 check out.

Because they can't go back in time and get the Debian server to accept the 
package.

 If you wanted to implement this the only safe way to do it and have the
 original packages by ex-developers still installable is to have a central
 daemon check the signature and co-sign the fact that they checked the
 signature at a certain date (upload date) and that it was valid as of that
 time.

Isn't the entire point of apt security extensions to make sure that the 
packages can only be accepted if they come from the Debian server not another 
server that impersonates it?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: init scripts and su

[Russell Coker]

On Tue, 27 Jul 2004 07:48, Andrew Pimlott [EMAIL PROTECTED] wrote:
  During the time between the daemon launch and it closing it's file
  handles and calling setsid(2) (which some daemons don't do because they
  are buggy) any other code running in the same UID could take over the
  process via ptrace, fork off a child process that inherits the
  administrator tty, and then stuff characters into the keyboard buffer
  with ioctl(fd,TIOCSTI,c) (*).

 If this is a real problem (which it sounds like), it's not specific to
 init scripts.  Shouldn't it be fixed in su?

Ideally yes.  But that involves proxying all operations on the pseudo-tty 
which is quite a difficult task.

 Maybe your changes should happen in su by default, with a --leak-tty
 option if you want to keep the terminal.

I can't imagine us changing the way su works by default.  The only way to make 
su user not have this problem by default is to proxy the pseudo-tty stuff.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: running services in their own little world

[Russell Coker]

On Mon, 26 Jul 2004 22:43, Milan P. Stanic [EMAIL PROTECTED] wrote:
  If so when will the patch be submitted to Linus?

 Who knows? These days patches doesn't get accepted so easy :-(

The SE Linux patches get accepted easily enough.  Most of the 2.6.x kernels 
have had SE Linux changes in them.

Adding a new LSM module is like adding a new device driver, people who choose 
not to use it will not even notice it's there, so there's nothing stopping 
Linus from adding them at any time.

It would be good if SE Linux wasn't the only security module in the kernel.org 
kernel tree.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: preventing /dev/kmem and /dev/mem writes?

[Russell Coker]

On Mon, 26 Jul 2004 22:54, [EMAIL PROTECTED] wrote:
 I have a machine that has been the unfortunate victime of SuckIT
 r00tkit. As this exploit relies on writing to /dev/kmem, I was thinking
 of making /dev/mem and /dev/kmem unwriteable. I have heard this breaks X
 and some gdb functions, but does anyone know any other specific problems
 this might have?

Some boot loaders need to access /dev/mem or /dev/kmem for getting BIOS data.  
Once your machine is in a bootable state you should not need /dev/k?mem for 
that.

klogd uses such access, probably for decoding Oops messages (it can probably 
operate fine without it for some loss of functionality).

vmware uses such access (and lots of other invasive access to kernel memory).

Many xdm type programs read kernel memory as a source of randomness.  This is 
bad because kernel memory is not random and it may leak some information from 
the kernel.  xdm in Fedora should be fixed to use /dev/random.

The X server needs such access if it's accessing the hardware directly.  If it 
uses the fbdev then it should not need such access.


The above is taken from the SE Linux policy.  Apart from the programs listed 
above in SE Linux nothing is granted such access.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: preventing /dev/kmem and /dev/mem writes?

[Russell Coker]

On Mon, 26 Jul 2004 23:38, [EMAIL PROTECTED] wrote:
   I have a machine that has been the unfortunate victime of SuckIT
   r00tkit. As this exploit relies on writing to /dev/kmem, I was thinking
   of making /dev/mem and /dev/kmem unwriteable. I have heard this breaks
   X and some gdb functions, but does anyone know any other specific
   problems this might have?
 
  Some boot loaders need to access /dev/mem or /dev/kmem for getting BIOS
  data. Once your machine is in a bootable state you should not need
  /dev/k?mem for that.

 but isn't that just read-only?

Yes.  But if you can read /dev/mem then you can probably find a copy 
of /etc/shadow and other useful stuff in there...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: preventing /dev/kmem and /dev/mem writes?

[Russell Coker]

On Tue, 27 Jul 2004 00:23, Michael Stone [EMAIL PROTECTED] wrote:
 On Mon, Jul 26, 2004 at 11:38:33PM +1000, [EMAIL PROTECTED] wrote:
 /dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as
 it doesn't support booting off RAID devices properly)

 Hmm. Seems to work here.

It seems that lilo code run in real mode puts some special data below 640K, 
and then the lilo installer which runs from Linux accesses /dev/mem to read 
it.

Whether this information is required depends on which lilo options you use.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: PaX on Debian

[Russell Coker]

On Mon, 26 Jul 2004 02:57, John Richard Moser [EMAIL PROTECTED] wrote:
 I'm interested in discussing the viability of PaX on Debian.  I'd like
 to discuss the changes to the base system that would be made, the costs
 in terms of overhead and compatibility, the gains in terms of security,
 and the mutability (elimination) of the costs.

Before we can even start thinking about PaX on Debian we need to find a 
maintainer for the kernel patch who will package new versions of the patch 
which apply to the Debian kernel source tree.  We have had a few flame-wars 
about this in the past which have had no positive result because no-one has 
volunteered to do the kernel coding work.

 A PaX protected base system would be best compiled ET_DYN, which can be
 done by using modified spec files or a specially patched gcc to make
 pies-by-default binaries.  Certain things don't compile this way; and
 thus would need this functionality disabled (modified spec, -fno-pic
 -nopie).  This will be discussed in greater detail later.

Debian does not use spec files, spec files are for RPM based distributions.  
It would have to be a modification to debian/rules in all the packages, or a 
modification to gcc and/or dpkg-buildpackage.

 A PaX protected base would also benefit from Stack Smash Protection,
 which can be done via the gcc patch ProPolice.  This imposes minimal
 overhead, which will be discussed in greater detail later.  It overlaps
 and extends many of the protections PaX offers, but catches earlier on;
 and is thus a good system to pair with PaX.

We have recently discussed this on at least one of the lists you posted to.  
The end result of the discussion is that GCC is getting another SSP type 
technology known as mudflap.  Mudflap depends on some major new features of 
GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the 
Debian GCC people don't want to merge in other patches which have no apparent 
chance of being included upstream.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: PaX on Debian

[Russell Coker]

On Mon, 26 Jul 2004 13:48, John Richard Moser [EMAIL PROTECTED] wrote:
 | Before we can even start thinking about PaX on Debian we need to find a
 | maintainer for the kernel patch who will package new versions of the
 | patch which apply to the Debian kernel source tree.  We have had a few

 Are you talking PaX or grsecurity?  PaX is significantly less invasive
 than grsecurity.  There will still be issues, of course.

PaX.  AFAIK the only PaX kernel-patch package in Debian is the Adamantix 
kernel source, which has RSBAC and a bunch of other stuff, and the GRSec 
patch.  Neither of them apply to the Debian kernel source tree.

 Where would I see debian's 2.6.7 source tree?  I'm not a deb user,
 remember, so I'll need a tarball or something.

http://ftp.debian.org/debian/pool/main/k/

 | We have recently discussed this on at least one of the lists you
 | posted to.

 | The end result of the discussion is that GCC is getting another SSP type
 | technology known as mudflap.  Mudflap depends on some major new
 | features of
 | GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
 | Debian GCC people don't want to merge in other patches which have no
 | apparent chance of being included upstream.

 Then don't use ProPolice/SSP for now.

That seems to be what will happen.  I'd rather see SSP included sooner, but I 
guess it won't happen.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

init scripts and su

[Russell Coker]

The start scripts for some daemons do su - user or use
start-stop-daemon -c to launch the daemon, postgresql is one example.

During the time between the daemon launch and it closing it's file handles and 
calling setsid(2) (which some daemons don't do because they are buggy) any 
other code running in the same UID could take over the process via ptrace, 
fork off a child process that inherits the administrator tty, and then stuff 
characters into the keyboard buffer with ioctl(fd,TIOCSTI,c) (*).

To address these issues for Fedora I have written a program named init_su.

init_su closes all file handles other than 1 and 2 (stdout and stderr).  File
handles 1 and 2 are fstat()'d, if they are regular files or pipes then they
are left open (no attack is possible through a file or pipe), otherwise they
are closed and /dev/null is opened instead.  /dev/null is opened for file
handle 0 regardless of what it might have pointed to previously.  Then
setsid() is called to create a new session for the process (make it a group
leader), this invalidates /dev/tty.  Then the uid is changed and the daemon
is started.


I have attached the source code to init_su, please check it out and tell me
what you think.  After the discussion concludes I will write a patch for 
start-stop-daemon to give similar functionality.


(*)  On system boot and shutdown there is no problem.  It's when the
administrator uses /etc/init.d/postgresql to start or stop the database that
there is potential for attack.


http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01314.html

I have also started a similar discussion on the Fedora development list about 
this issue, see the above URL.

--
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page
#include stdio.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include pwd.h
#include stdlib.h
#include unistd.h
#include syslog.h

void usage(const char * const msg)
{
  if(msg)
fprintf(stderr, Error: %s\n\n, msg);
  fprintf(stderr, Usage: init_su [-l] user -c command\n);
  exit(1);
}

int main(int argc, char **argv)
{
  int i, fd;
  int login = 0;
  char *command = NULL, *user = NULL, *shell = NULL, *nu_argv[4];
  struct passwd *pw;

  int int_c = 0;
  while(int_c != -1)
  {
int_c = getopt(argc, argv, -lc:s:);
switch(int_c)
{
  case 1:
if(!strcmp(optarg, -))
{
  login = 1;
}
else
{
  user = optarg;
}
  break;
  case 'l':
login = 1;
  break;
  case 's':
shell = optarg;
  break;
  case 'c':
command = optarg;
  break;
}
  }
  if(!user || !command)
usage(NULL);
  pw = getpwnam(user);
  if(!pw)
usage(User unknown.);
  if(setregid(pw-pw_gid, pw-pw_gid))
usage(Can't setgid(), are you root?);
  if(setreuid(pw-pw_uid, pw-pw_uid))
usage(Can't setuid(), are you root?);
  if(!shell)
shell = pw-pw_shell;
  if(login)
  {
nu_argv[0] = strrchr(shell, '/');
if(!nu_argv[0])
  usage(Bad shell.);
nu_argv[0] = strdup(nu_argv[0]);
nu_argv[0][0] = '-';
  }
  else
nu_argv[0] = shell;
  nu_argv[1] = -c;
  nu_argv[2] = command;
  nu_argv[3] = NULL;
  close(0);
  for(i = 3; i  1024; i++)
close(i);
  openlog(initrc_su, LOG_CONS | LOG_NOWAIT, LOG_DAEMON);
  fd = open(/dev/null, O_RDWR);
  if(fd == -1)
  {
syslog(LOG_ERR, Can't open /dev/null when trying to execute program %s, command);
return 1;
  }
  for(i = 0; i  3; i++)
  {
struct stat sbuf;
if(i != fd  (fstat(i, sbuf) == -1 || (!S_ISREG(sbuf.st_mode)  !S_ISFIFO(sbuf.st_mode)) ))
{
  close(i);
  if(dup2(fd, i) != i)
  {
syslog(LOG_ERR, Can't dup2() when trying to execute program %s, command);
return 1;
  }
}
  }
  if(fd = 3)
close(fd);
  setsid();  /* it's OK if this fails as we get the right result anyway */
  execv(shell, nu_argv);
  syslog(LOG_ERR, Can't exec program %s, command);
  return 1;
}

Re: My details

[Russell Coker]

On Sat, 3 Jul 2004 10:28, LOGAN Jim [EMAIL PROTECTED] wrote:
 WHO  R  U  FUCKIN' BASTARD  ?
 I HATE THE BLOODY MOTHER FUCKERS LIKE U !
 I DON' T LIKE YOUR DAMN' VIRUS , SON OF A BITCH ! ...I' LL GET
 YOUR BLOODY SKIN ! WOLVERINE

Does your mother know you talk like that?

The debian-security list has nothing to do with the virus you received.  It 
probably came from one of your friends who uses Outlook.


PS  This is a good example of why children should be supervised when using the 
Internet.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: password managers

[Russell Coker]

On Tue, 15 Jun 2004 18:46, Alberto Gonzalez Iniesta [EMAIL PROTECTED] wrote:
 Some of the applications I run use kwallet, that seems similar to what
 Russell Cooker described for OS X.

No.  kwallet can be ptraced, this allows a hostile program to get access to 
all it's data with ease.

Of course in OS/X I expect that you could fool the password manager somehow to 
get access.  But at least they stop ptrace.

Also kwallet seems to have no features for restricting access to data.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Kernel Crash Bug????

[Russell Coker]

On Tue, 15 Jun 2004 17:24, Rudy Gevaert [EMAIL PROTECTED] wrote:
 Would it be possible to run that program trough e.g. perl/php/... ?

 A use could ftp the executable and write a php script that execute it.

Does PHP allow executing arbitary binaries?

If the user can install CGI-BIN scripts then that's a good way of running a 
kernel security attack (or other local or back-end network attack).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: password managers

[Russell Coker]

On Tue, 15 Jun 2004 18:46, Alberto Gonzalez Iniesta [EMAIL PROTECTED] wrote:
 Some of the applications I run use kwallet, that seems similar to what
 Russell Cooker described for OS X.

No.  kwallet can be ptraced, this allows a hostile program to get access to 
all it's data with ease.

Of course in OS/X I expect that you could fool the password manager somehow to 
get access.  But at least they stop ptrace.

Also kwallet seems to have no features for restricting access to data.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Kernel Crash Bug????

[Russell Coker]

On Tue, 15 Jun 2004 17:24, Rudy Gevaert [EMAIL PROTECTED] wrote:
 Would it be possible to run that program trough e.g. perl/php/... ?

 A use could ftp the executable and write a php script that execute it.

Does PHP allow executing arbitary binaries?

If the user can install CGI-BIN scripts then that's a good way of running a 
kernel security attack (or other local or back-end network attack).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: rbl's status?

[Russell Coker]

On Mon, 14 Jun 2004 16:39, Adrian 'Dagurashibanipal' von Bidder 
[EMAIL PROTECTED] wrote:
 Also you may want to look at the rfc-ignorant.org ones, but reading
 nanae I got the impression that they are more trouble than they're
 worth.

This thread inspired me to fiddle with my anti-spam settings again.  Below is 
my current Postfix configuration for those who are interested.

My latest addition is RHSBL entries.  So far rhsbl.sorbs.net has not caught 
anything (only been on for about 30 mins and it's late in the list).  The 
rfc-ignorant.org entries have been catching a lot, one thing that they cught 
is yahoo.com because [EMAIL PROTECTED] allegedly doesn't work.  I've just sent 
a test message to [EMAIL PROTECTED] and it hasn't bounced yet...  Maybe the 
Yahoo abuse team are being butt-head's about clicking on the removal URL.

smtpd_client_restrictions = permit_mynetworks, reject_rbl_client 
bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client 
list.dsbl.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client 
dnsbl.njabl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client 
relays.ordb.org, reject_rhsbl_client rhsbl.sorbs.net, reject_rhsbl_client 
dsn.rfc-ignorant.org, reject_rhsbl_client postmaster.rfc-ignorant.org

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: password managers

[Russell Coker]

On Tue, 15 Jun 2004 04:56, andrew lattis [EMAIL PROTECTED] wrote:
 currently i've got an ever growing password list in a plain text file
 stored on an encrypted loopback fs, this is getting cumbersome...

 figaro's password manager (package fpm) looks nice and uses blowfish to
 encrypt data but i can't find anything showing any type of third party
 audit.

 what does everyone else use to keep track of all there passwords?

OS/X from Apple has a password manager program, it allows passwords to be made 
available to applications for certain time periods (not sure how this is 
supposed to work as the application could just write it to disk).

I think that an ideal password management scheme would be mediated by a SGID 
application (SGID so that it can access storage unavailable to regular user 
processes and so that it can't be ptraced).

Password storage would be either in a file owned by the user that is mode 0600 
under a mode 1770 system directory with group ownership being the group that 
the management program is SGID to, or a regular file in the home directory 
that is encrypted (requiring a password authentication for the first login of 
the day or something similar).

The password management system would need to have helpers for managing 
passwords that would be called by the application.  For example there would 
be POP and IMAP helpers which would establish a connection to the mail 
server, authenticate, and then use a unix domain socket to pass the file 
handle for the TCP socket back to the calling application (so the MUA would 
never be able to recover the password).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: rbl's status?

[Russell Coker]

On Mon, 14 Jun 2004 16:39, Adrian 'Dagurashibanipal' von Bidder 
[EMAIL PROTECTED] wrote:
 Also you may want to look at the rfc-ignorant.org ones, but reading
 nanae I got the impression that they are more trouble than they're
 worth.

This thread inspired me to fiddle with my anti-spam settings again.  Below is 
my current Postfix configuration for those who are interested.

My latest addition is RHSBL entries.  So far rhsbl.sorbs.net has not caught 
anything (only been on for about 30 mins and it's late in the list).  The 
rfc-ignorant.org entries have been catching a lot, one thing that they cught 
is yahoo.com because [EMAIL PROTECTED] allegedly doesn't work.  I've just sent 
a test message to [EMAIL PROTECTED] and it hasn't bounced yet...  Maybe the 
Yahoo abuse team are being butt-head's about clicking on the removal URL.

smtpd_client_restrictions = permit_mynetworks, reject_rbl_client 
bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client 
list.dsbl.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client 
dnsbl.njabl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client 
relays.ordb.org, reject_rhsbl_client rhsbl.sorbs.net, reject_rhsbl_client 
dsn.rfc-ignorant.org, reject_rhsbl_client postmaster.rfc-ignorant.org

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: password managers

[Russell Coker]

On Tue, 15 Jun 2004 04:56, andrew lattis [EMAIL PROTECTED] wrote:
 currently i've got an ever growing password list in a plain text file
 stored on an encrypted loopback fs, this is getting cumbersome...

 figaro's password manager (package fpm) looks nice and uses blowfish to
 encrypt data but i can't find anything showing any type of third party
 audit.

 what does everyone else use to keep track of all there passwords?

OS/X from Apple has a password manager program, it allows passwords to be made 
available to applications for certain time periods (not sure how this is 
supposed to work as the application could just write it to disk).

I think that an ideal password management scheme would be mediated by a SGID 
application (SGID so that it can access storage unavailable to regular user 
processes and so that it can't be ptraced).

Password storage would be either in a file owned by the user that is mode 0600 
under a mode 1770 system directory with group ownership being the group that 
the management program is SGID to, or a regular file in the home directory 
that is encrypted (requiring a password authentication for the first login of 
the day or something similar).

The password management system would need to have helpers for managing 
passwords that would be called by the application.  For example there would 
be POP and IMAP helpers which would establish a connection to the mail 
server, authenticate, and then use a unix domain socket to pass the file 
handle for the TCP socket back to the calling application (so the MUA would 
never be able to recover the password).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Spam fights

[Russell Coker]

On Sat, 12 Jun 2004 04:22, s. keeling [EMAIL PROTECTED] wrote:
 Incoming from Rick Moen:
  Quoting Russell Coker ([EMAIL PROTECTED]):
   Some of the anti-spam people are very enthusiastic about their work.  I
   wouldn't be surprised if someone writes a bot to deal with CR systems.
 
  A bot to detect C-R queries and add them to the refused-mail ACL list
  would be most useful.  ;-

 A better one would be one that successfully negotiates the C-R
 itself.  Then we can give the spammers a copy and teach the C-R
 nitwits a lesson.

Proof that I am correct.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Spam fights

[Russell Coker]

On Sat, 12 Jun 2004 04:22, s. keeling [EMAIL PROTECTED] wrote:
 Incoming from Rick Moen:
  Quoting Russell Coker ([EMAIL PROTECTED]):
   Some of the anti-spam people are very enthusiastic about their work.  I
   wouldn't be surprised if someone writes a bot to deal with CR systems.
 
  A bot to detect C-R queries and add them to the refused-mail ACL list
  would be most useful.  ;-

 A better one would be one that successfully negotiates the C-R
 itself.  Then we can give the spammers a copy and teach the C-R
 nitwits a lesson.

Proof that I am correct.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 19:29, Dale Amon [EMAIL PROTECTED] wrote:
 On Fri, Jun 11, 2004 at 10:45:44AM +1000, Russell Coker wrote:
  It is anti-social for every idiot on the net to think that they are
  important enough to require a subscription from everyone who wants to
  send them email.

 Like it or not (and I don't) that is where we are
 headed if other solutions to spam are not implimented
 that cover non-NANOG type persons. I strongly suspect

It won't work because challenge-response systems are technically no good.  
While CR systems are almost never used because the people who use them are 
universally regarded as cretins, the spammers won't bother about trying to 
fool them.

If CR systems get popular then spammers will start replying to the messages.  
Most spammers have working email addresses, so it would not be difficult to 
automate a response to a CR system.  Any CR system which just requires that 
you reply to this email will be trivially broken by spammers.

One CR system I saw used a web page with some obscured text that is 
(supposedly) only readable by humans.  There are two ways of solving this (if 
it ever becomes popular).  One way is to make entering such things a 
condition for downloading free porn from a porn site (a document on using 
porn sites to subscribe to hotmail etc was published some time ago).  The 
other way is better OCR software.

Finally, a large chunk of spam is entered by humans.  The Nigerian spammers 
often do things manually with cut/paste and don't have software to automate 
it (a friend witnessed a Nigerian spammer doing this at an Internet cafe).  
Such people will get past any CR system that could be devised.

 we'll see a generation of mail systems which greylist
 by default at the very least. Perhaps a future
 secreterial job will be to wade through the muck and
 query the boss as to whether one or two should be
 allowed access.

That is a secretarial job today.  Some people (such as Bill Gates) employ a 
team of people to filter their email.

 For some people, even the volume of non-spam mail
 could be rather intolerable. Imagine if you were
 Tom Hanks and your private email got out and you
 had to go through thousands of adoring fan mails
 to find that movie contract from your agent...

It's quite easy to search on From: field.  Of course you need a decently fast 
Internet connection to download all the messages, but I'm sure Tom can afford 
that.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 21:38, Dale Amon [EMAIL PROTECTED] wrote:
 That said, those who can afford it will hire human
 operators to act as email gatekeepers; those who can't
 will use whatever a salesman can convince them is
 affordable and works. Whether we like it or not will
 not figure into the decision.

Some of the anti-spam people are very enthusiastic about their work.  I 
wouldn't be surprised if someone writes a bot to deal with CR systems.

It should not be technically difficult to publish some email addresses, wait 
for challenge messages to come in response to virus messages, and then have 
it automatically send an appropriate response to the challenge followed by a 
series of flames.

 As to the type in this random code from a jpeg,
 I use that on samizdata (a major blog for which I'm
 one of the editors). It stopped the problem of blog-spam
 cold; the human entry is stopped cold by having
 a team of writers who delete on sight.

One - many communication is different.  If you want to get a letter to the 
editor published in a newspaper you have to confirm your identity and contact 
details before it will be considered.  This can involve a journalist phoning 
you to confirm your identity and permission for publication.  If you want to 
send mail to most mailing lists you have to subscribe first.  Blogs are in 
the same category so I agree with what you are doing there.

 At the end of the day, dealing with spam is an
 employment opportunity, not something that will be
 solved technically. Human problems require human
 solutions.

Sometimes human solutions involve humans writing and installing programs to 
implement them.  Totally stopping spam in an automatic manner is not 
possible.  Reducing it by a factor of 100 so that humans can manually deal 
with the residue is possible.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Hashcash - was re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 22:34, Patrick Maheral [EMAIL PROTECTED] wrote:
 It seems that most people here don't like CR systems, and I'd have to
 agree with that consensus.

 I'm just wondering what is the general feeling about using hashcash and
 other header signatures systems.

Currently you can't accept only such messages because almost no-one sends 
them.  Most people see no need to send them because almost no-one checks for 
them when receiving a message.

Anti-spam measures may be used on workstations eventually, but have to be 
initially installed at servers if they are to become popular.  The people who 
run big mail servers (AOL, Hotmail, etc) don't want to install hashcash for 
the same reason that spammers won't install it.

Besides, with an army of Windows Zombies you could generate those signatures 
anyway...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Hashcash - was re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 23:43, [EMAIL PROTECTED] (Rens Houben) wrote:
 In other news for Fri, Jun 11, 2004 at 11:24:05PM +1000, Russell Coker has 
been seen typing:
  Besides, with an army of Windows Zombies you could generate those
  signatures anyway...

 Why bother, when said windows machines will have perfectly good
 signatures stored on them somewhere already?

Presumably the signature would be based on the envelope recipient and 
therefore signatures you find on someone else's machine would not do any 
good.  If it was otherwise then a single signature would work for an entire 
spam run.

I am assuming that the sending machine would not store the signatures for 
messages it sent, which could be re-used if the spam messages were to have an 
ancient time-stamp.  However this still wouldn't be of any great use, not 
many people have more than 10,000 messages stored in their sent-mail folder 
and the common case is far less.  Capturing a lot of zombies to generate 
signatures would probably be easier than trying to find a machine that had a 
large sent-mail folder.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 19:29, Dale Amon [EMAIL PROTECTED] wrote:
 On Fri, Jun 11, 2004 at 10:45:44AM +1000, Russell Coker wrote:
  It is anti-social for every idiot on the net to think that they are
  important enough to require a subscription from everyone who wants to
  send them email.

 Like it or not (and I don't) that is where we are
 headed if other solutions to spam are not implimented
 that cover non-NANOG type persons. I strongly suspect

It won't work because challenge-response systems are technically no good.  
While CR systems are almost never used because the people who use them are 
universally regarded as cretins, the spammers won't bother about trying to 
fool them.

If CR systems get popular then spammers will start replying to the messages.  
Most spammers have working email addresses, so it would not be difficult to 
automate a response to a CR system.  Any CR system which just requires that 
you reply to this email will be trivially broken by spammers.

One CR system I saw used a web page with some obscured text that is 
(supposedly) only readable by humans.  There are two ways of solving this (if 
it ever becomes popular).  One way is to make entering such things a 
condition for downloading free porn from a porn site (a document on using 
porn sites to subscribe to hotmail etc was published some time ago).  The 
other way is better OCR software.

Finally, a large chunk of spam is entered by humans.  The Nigerian spammers 
often do things manually with cut/paste and don't have software to automate 
it (a friend witnessed a Nigerian spammer doing this at an Internet cafe).  
Such people will get past any CR system that could be devised.

 we'll see a generation of mail systems which greylist
 by default at the very least. Perhaps a future
 secreterial job will be to wade through the muck and
 query the boss as to whether one or two should be
 allowed access.

That is a secretarial job today.  Some people (such as Bill Gates) employ a 
team of people to filter their email.

 For some people, even the volume of non-spam mail
 could be rather intolerable. Imagine if you were
 Tom Hanks and your private email got out and you
 had to go through thousands of adoring fan mails
 to find that movie contract from your agent...

It's quite easy to search on From: field.  Of course you need a decently fast 
Internet connection to download all the messages, but I'm sure Tom can afford 
that.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 21:38, Dale Amon [EMAIL PROTECTED] wrote:
 That said, those who can afford it will hire human
 operators to act as email gatekeepers; those who can't
 will use whatever a salesman can convince them is
 affordable and works. Whether we like it or not will
 not figure into the decision.

Some of the anti-spam people are very enthusiastic about their work.  I 
wouldn't be surprised if someone writes a bot to deal with CR systems.

It should not be technically difficult to publish some email addresses, wait 
for challenge messages to come in response to virus messages, and then have 
it automatically send an appropriate response to the challenge followed by a 
series of flames.

 As to the type in this random code from a jpeg,
 I use that on samizdata (a major blog for which I'm
 one of the editors). It stopped the problem of blog-spam
 cold; the human entry is stopped cold by having
 a team of writers who delete on sight.

One - many communication is different.  If you want to get a letter to the 
editor published in a newspaper you have to confirm your identity and contact 
details before it will be considered.  This can involve a journalist phoning 
you to confirm your identity and permission for publication.  If you want to 
send mail to most mailing lists you have to subscribe first.  Blogs are in 
the same category so I agree with what you are doing there.

 At the end of the day, dealing with spam is an
 employment opportunity, not something that will be
 solved technically. Human problems require human
 solutions.

Sometimes human solutions involve humans writing and installing programs to 
implement them.  Totally stopping spam in an automatic manner is not 
possible.  Reducing it by a factor of 100 so that humans can manually deal 
with the residue is possible.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Hashcash - was re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 22:34, Patrick Maheral [EMAIL PROTECTED] wrote:
 It seems that most people here don't like CR systems, and I'd have to
 agree with that consensus.

 I'm just wondering what is the general feeling about using hashcash and
 other header signatures systems.

Currently you can't accept only such messages because almost no-one sends 
them.  Most people see no need to send them because almost no-one checks for 
them when receiving a message.

Anti-spam measures may be used on workstations eventually, but have to be 
initially installed at servers if they are to become popular.  The people who 
run big mail servers (AOL, Hotmail, etc) don't want to install hashcash for 
the same reason that spammers won't install it.

Besides, with an army of Windows Zombies you could generate those signatures 
anyway...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Hashcash - was re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 23:43, [EMAIL PROTECTED] (Rens Houben) wrote:
 In other news for Fri, Jun 11, 2004 at 11:24:05PM +1000, Russell Coker has 
been seen typing:
  Besides, with an army of Windows Zombies you could generate those
  signatures anyway...

 Why bother, when said windows machines will have perfectly good
 signatures stored on them somewhere already?

Presumably the signature would be based on the envelope recipient and 
therefore signatures you find on someone else's machine would not do any 
good.  If it was otherwise then a single signature would work for an entire 
spam run.

I am assuming that the sending machine would not store the signatures for 
messages it sent, which could be re-used if the spam messages were to have an 
ancient time-stamp.  However this still wouldn't be of any great use, not 
many people have more than 10,000 messages stored in their sent-mail folder 
and the common case is far less.  Capturing a lot of zombies to generate 
signatures would probably be easier than trying to find a machine that had a 
large sent-mail folder.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Spam fights

[Russell Coker]

On Thu, 10 Jun 2004 18:21, Jaroslaw Tabor [EMAIL PROTECTED] wrote:
 We are allowing all emails from whitelits.

Who is we in this context?  Individual users or mailing list administrators?

 For unknown sender, automated confirmation request is send. If

For mailing lists this can be achieved by making the list subscriber-only.  
For individual accounts such behaviour is very anti-social as it results in 
confirmation messages being sent in response to virus messages.  This means 
that even though my anti-virus software is updated regularly I still get hit 
by viruses through those stupid confirmation messages!

My response to these scumbags who send me the confirmation messages is that if 
they are on a mailing list I'm on then I black-list their email address if 
it's known (or their mail server if their email address is not clear).  If a 
confirmation message appears to be in response to a virus then I respond to 
it.  Let the scumbag get another copy of the virus...

 I'm planning to develop this feauture, but It will be nice to hear from
 what you thing about this idea.

Don't do it.  Confirmation systems are just as bad as the problems that they 
try to solve.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 06:03, Alain Tesio [EMAIL PROTECTED] wrote:
 On Thu, 10 Jun 2004 18:58:33 +1000

 Russell Coker [EMAIL PROTECTED] wrote:
  For mailing lists this can be achieved by making the list
  subscriber-only. For individual accounts such behaviour is very
  anti-social as it results in confirmation messages being sent in response
  to virus messages.

 Not if the message if refused by the smtp server before it's delivered,
 right ? It's not that antisocial to ask the 1% people who aren't subscribed
 to subscribe before sending a message.

It is not anti-social for a mailing list of (potentially) thousands of people 
to require a subscription before posting.

It is anti-social for every idiot on the net to think that they are important 
enough to require a subscription from everyone who wants to send them email.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Spam fights

[Russell Coker]

On Fri, 11 Jun 2004 06:03, Alain Tesio [EMAIL PROTECTED] wrote:
 On Thu, 10 Jun 2004 18:58:33 +1000

 Russell Coker [EMAIL PROTECTED] wrote:
  For mailing lists this can be achieved by making the list
  subscriber-only. For individual accounts such behaviour is very
  anti-social as it results in confirmation messages being sent in response
  to virus messages.

 Not if the message if refused by the smtp server before it's delivered,
 right ? It's not that antisocial to ask the 1% people who aren't subscribed
 to subscribe before sending a message.

It is not anti-social for a mailing list of (potentially) thousands of people 
to require a subscription before posting.

It is anti-social for every idiot on the net to think that they are important 
enough to require a subscription from everyone who wants to send them email.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Unusual spam recently - hummm - postprocess

[Russell Coker]

On Sat, 5 Jun 2004 08:52, Michael Stone [EMAIL PROTECTED] wrote:
 So, adding handling for SPF RRs in one's MTA yields significant
 advantages today, despite the technology being new, because _all_ of the
 forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com,
 etc. can be detected all in one step.

 Well, I guess the spammers will have to use different addresses. That
 shouldn't take long.

Which leads to more spam that uses addresses from small domains in the From: 
field, and thus more need for administrators of small servers to implement 
SPF records to counter it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Unusual spam recently - hummm - postprocess

[Russell Coker]

On Sat, 5 Jun 2004 08:52, Michael Stone [EMAIL PROTECTED] wrote:
 So, adding handling for SPF RRs in one's MTA yields significant
 advantages today, despite the technology being new, because _all_ of the
 forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com,
 etc. can be detected all in one step.

 Well, I guess the spammers will have to use different addresses. That
 shouldn't take long.

Which leads to more spam that uses addresses from small domains in the From: 
field, and thus more need for administrators of small servers to implement 
SPF records to counter it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: makedev: /dev/tty([0-9])* should not have 666 permissions

[Russell Coker]

On Tue, 20 Apr 2004 07:50, Jan Minar [EMAIL PROTECTED] wrote:
 It seems like they should be 660, not 600, as I suggested (wall(1) and
 talkd(1) would break otherwise, probably).

What prevents wall from sending those escape sequences?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: makedev: /dev/tty([0-9])* should not have 666 permissions

[Russell Coker]

On Tue, 20 Apr 2004 07:50, Jan Minar [EMAIL PROTECTED] wrote:
 It seems like they should be 660, not 600, as I suggested (wall(1) and
 talkd(1) would break otherwise, probably).

What prevents wall from sending those escape sequences?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: logcheck.ignore entries

[Russell Coker]

On Thu, 15 Apr 2004 02:01, Jeff Coppock [EMAIL PROTECTED] wrote:
 I'm having trouble with getting entries here to work.  I have the
 following /var/log/auth.log messages that I want to filter out of
 logcheck (version 1.2.16, sarge):

 CRON[15302]: (pam_unix) session opened for user root by (uid=0)
 CRON[15302]: (pam_unix) session closed for user root
 CRON[15613]:(pam_unix) session opened for user mail by (uid=0)
 CRON[15613]:(pam_unix) session closed for user mail

 So, I have the following entry in /etc/logcheck/logcheck.ignore:

Try this one:
CRON\[.*\]:( )?\(pam_unix\) session (opened)|(closed) for user (root)|(mail)

You hadn't accounted for the optional space after the ':' (or was that a 
typo?), the \[.*\] part is better than just a .* (imagine if you could 
fool cron about the user-name to log), also a .* on the end is redundant.  
For having two different words match you need to put each word in braces, 
(opened|closed) is the same as opene(d|c)losed.

For the benefit of other readers, '.' in a regular expression matches any 
character and '*' means zero or more instances of the previous atom.  See 
regex(7) for more details.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: logcheck.ignore entries

[Russell Coker]

On Thu, 15 Apr 2004 02:01, Jeff Coppock [EMAIL PROTECTED] wrote:
 I'm having trouble with getting entries here to work.  I have the
 following /var/log/auth.log messages that I want to filter out of
 logcheck (version 1.2.16, sarge):

 CRON[15302]: (pam_unix) session opened for user root by (uid=0)
 CRON[15302]: (pam_unix) session closed for user root
 CRON[15613]:(pam_unix) session opened for user mail by (uid=0)
 CRON[15613]:(pam_unix) session closed for user mail

 So, I have the following entry in /etc/logcheck/logcheck.ignore:

Try this one:
CRON\[.*\]:( )?\(pam_unix\) session (opened)|(closed) for user (root)|(mail)

You hadn't accounted for the optional space after the ':' (or was that a 
typo?), the \[.*\] part is better than just a .* (imagine if you could 
fool cron about the user-name to log), also a .* on the end is redundant.  
For having two different words match you need to put each word in braces, 
(opened|closed) is the same as opene(d|c)losed.

For the benefit of other readers, '.' in a regular expression matches any 
character and '*' means zero or more instances of the previous atom.  See 
regex(7) for more details.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Server slowdown...

[Russell Coker]

On Mon, 12 Apr 2004 10:00, Joe Bouchard [EMAIL PROTECTED] wrote:
 In a meeting at work (I'm part of the IT group at a large corporation)
 someone mentioned a particular kind of network hardware which would stop
 working correctly after a while.

Here are some ways that network issues can slow down a server:

On shared media (such as 10base2) accidentally leave an interface in 
promiscuous mode (there used to be a bug in tcpdump whereby running two 
copies of it at the same time could cause the interface to remain in 
promiscuous mode after both copies had exited).  A moderately busy 10base2 
could destroy the performance of a decent 1995 server machine if an interface 
was in promiscuous mode, and as the CPU use occurred in interrupt context 
none of the usual tools would tell you what was happening.

Send lots of minimal size packets to a server or to the media broadcast 
address.  Until recently minimal size packets on 10Mb media could destroy the 
performance of most systems.  Now with Gig-E even using 1500 byte packets you 
can destroy the performance of most systems.

If you had a router break and repeatedly send a single IP datagram to your 
server on a Gig-E link then the likely result would be a dramatic loss of 
performance.

If you suspect this then the best thing to do is run a program to measure 
system performance on the console and unplug the network cables.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: VPN Firewall Kernel

[Russell Coker]

On Thu, 1 Apr 2004 17:59, [EMAIL PROTECTED] (Michael Becker) wrote:
 If you just want a kernel, with almost everything in there belonging
 to security, have a look at WOLK (Working OverLoaded Kernel)
 at  http://sourceforge.net/projects/wolk

It appears that WOLK is not in Debian.  I would guess that given it's aim to 
include as many patches as possible it would conflict with most other kernel 
patches (including the Debian kernel patch).  If you feel that the Debian 
kernel-source packages provide no benefit for you then this may be OK.

Neither the URL you provide nor the Freshmeat entry list what patches are 
included in WOLK.

In Debian there are patches for exec-shield, SE Linux, GRSecurity, and the 
Adamantix kernel patch (PAX + RSBAC + maybe some other things).

If you use one of the kernel patch packages in Debian then it will usually 
apply to the Debian kernel-source packages, and you can have some expectation 
of it being maintained for future kernel versions.  Also there is a better 
chance that other Debian kernel patches will work with it.  You might 
consider that this is not a problem if you have the skill and time to merge 
patches whenever you build a new kernel, but it can be convenient to save the 
time.

Another option is to use a kernel source tree provided by another 
distribution.  The Hardened Gentoo people are doing some interesting stuff 
in regard to kernel security patches.  Compiling Gentoo kernel source on and 
for a Debian machine should not cause any problems.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: passwords changed?

[Russell Coker]

On Sat, 10 Apr 2004 04:22, [EMAIL PROTECTED] wrote:
 Is there anything ordinary that can cause passwords to be changed? I tried
 to log in last night and sshd wouldn't accept either my user's password or
 my root password. When I got physical access this morning, I couldn't log
 into the console either.

 So, my first though is that I got rooted, and so I pulled the ethernet
 cable. However, I thought that the idea of a rootkit was to hide any
 evidence. So, changing the passwords wouldn't be something normal

Root kits are often used by people who are a lot less intelligent than the 
people who wrote them.  Also there is no requirement that someone who cracks 
your machine install a root kit.

When was the last time you could login?  Have you done any changes since then?  
Try copying the /etc/passwd and /etc/shadow to a test machine and see if it 
lets you login then (IE test if it is actually a password change or something 
broken in PAM etc).

 The system is actually Redhat 8.0 (not my choice) fully up to date, or as
 up to date as redhat lets you get nowadays. The 2 services running are sshd
 and proftpd. I'm definetly putting debian on it, if it does turn out to be
 rooted.

What versions of sshd and proftpd?  Both of them have had security issues at 
various times.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: passwords changed?

[Russell Coker]

On Sat, 10 Apr 2004 04:22, [EMAIL PROTECTED] wrote:
 Is there anything ordinary that can cause passwords to be changed? I tried
 to log in last night and sshd wouldn't accept either my user's password or
 my root password. When I got physical access this morning, I couldn't log
 into the console either.

 So, my first though is that I got rooted, and so I pulled the ethernet
 cable. However, I thought that the idea of a rootkit was to hide any
 evidence. So, changing the passwords wouldn't be something normal

Root kits are often used by people who are a lot less intelligent than the 
people who wrote them.  Also there is no requirement that someone who cracks 
your machine install a root kit.

When was the last time you could login?  Have you done any changes since then?  
Try copying the /etc/passwd and /etc/shadow to a test machine and see if it 
lets you login then (IE test if it is actually a password change or something 
broken in PAM etc).

 The system is actually Redhat 8.0 (not my choice) fully up to date, or as
 up to date as redhat lets you get nowadays. The 2 services running are sshd
 and proftpd. I'm definetly putting debian on it, if it does turn out to be
 rooted.

What versions of sshd and proftpd?  Both of them have had security issues at 
various times.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: name based virtual host and apache-ssl

[Russell Coker]

On Wed, 24 Mar 2004 22:22, Michael Stone [EMAIL PROTECTED] wrote:
 The best you could do would be to attach different certificates to
 different ports, but that would be extremely cumbersome and probably
 would lead to confusion.

What if you had http://www.company1.com/ redirect to 
https://www.company1.com:81/ and http://www.company2.com/ redirect to 
https://www.company2.com:82/ ?

www.company1.com and www.company2.com would have the same IP address.  This 
should work.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: name based virtual host and apache-ssl

[Russell Coker]

On Wed, 24 Mar 2004 22:22, Michael Stone [EMAIL PROTECTED] wrote:
 The best you could do would be to attach different certificates to
 different ports, but that would be extremely cumbersome and probably
 would lead to confusion.

What if you had http://www.company1.com/ redirect to 
https://www.company1.com:81/ and http://www.company2.com/ redirect to 
https://www.company2.com:82/ ?

www.company1.com and www.company2.com would have the same IP address.  This 
should work.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Cron - was Known vulnerabilities left open in Debian?

[Russell Coker]

On Tue, 23 Mar 2004 08:19, Florian Weimer [EMAIL PROTECTED] wrote:
 No, it's another example for a package which heavily deviates from
 upstream (AFAIK, upstream is defunct) and is now developed by the
 GNU/Linux distributions (and each variant has a slightly different
 features).  Despite this, the situation with cron is rather good;
 its complexity is not so high that it's close to impossible to port back
 security bugs.

Cron is a good candidate for a fork.  Cron is not THAT difficult in terms of 
coding, assembling a small team with representatives from all major 
distributions to maintain a fork of Vixie cron should be doable.

Another option is using Dillon cron or fcron as a replacement.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Cron - was Known vulnerabilities left open in Debian?

[Russell Coker]

On Tue, 23 Mar 2004 08:19, Florian Weimer [EMAIL PROTECTED] wrote:
 No, it's another example for a package which heavily deviates from
 upstream (AFAIK, upstream is defunct) and is now developed by the
 GNU/Linux distributions (and each variant has a slightly different
 features).  Despite this, the situation with cron is rather good;
 its complexity is not so high that it's close to impossible to port back
 security bugs.

Cron is a good candidate for a fork.  Cron is not THAT difficult in terms of 
coding, assembling a small team with representatives from all major 
distributions to maintain a fork of Vixie cron should be doable.

Another option is using Dillon cron or fcron as a replacement.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page