Re: security: version update: version 0.1.14 beta-15 (was: Insecure lockfile creation - vulnerability report)
On Thu, Mar 27, 2008 at 11:52:17PM +0100, Andrej Kacian wrote:
On Tue, 25 Mar 2008 01:40:31 +0100
Robert Felber [EMAIL PROTECTED] wrote:
the new version addresses the issue below. Policyd-weight does now exit if
it
detects symlinks on directories or sockets at startup or directory creation.
Hello Robert,
I'm afraid 0.1.14.15 doesn't fix the issue reported.
By symlinking /tmp/.policyd-weight to /root and starting policyd-weight, I was
still able to change ownership of /root directory to user policyd-weight is
configured to run as.
Thanks for reporting.
This is weird, and I am a little bit confused:
# perl -wle 'if(-l /tmp/.policyd-weight){ print err }'
err
The question is now, why the same test in policyd-weight is
not resulting in a true value.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
Policyd-weight Mailinglist - http://www.policyd-weight.org/
security: version update: version 0.1.14 beta-17
Hello, policyd-weight still did not check the working directory correctly. 1st: I assumed [ -L /foo/bar ] is the same as [ -L /foo/bar/ ] because the -L tells the file test what to look for. But in the latter form it is checked with S_IFDIR. We normalize the path with File::Spec-canonpath as s,/+$,, is not sufficient. 2nd: policyd-weight didn't check the ownership of real directories which might have been resulted in a race attack. Policyd-weight once gets the stat/lstat and reuses that information in order to provide some sort of atomicity of the check_symlnk() sub-routine. MD5 (policyd-weight)= 68373b7cfeda52b78df6229ed658771e SHA256 (policyd-weight) = 4245495685e516e00a363a97aaa17456f48c51fcbdb4458989a9d68db64083bc MD5 (policyd-weight-0.1.14.17.tar.gz) = c90128d2442ba343e8127dc0dbdcfd9a SHA256 (policyd-weight-0.1.14.17.tar.gz)= c13bac397cbd8c018b41686da4e4ce9450fb045752d7f0ab518d9836b39dbf36 -- Robert Felber (PGP: 896CF30B) Munich, Germany Policyd-weight Mailinglist - http://www.policyd-weight.org/
Thanks for fix, Website slightly confused
Hi, At the moment policyd-weight Version: 0.1.14 beta-17 links to beta-15, while devel version 0.1.14 beta-17 does link to beta-17, and You are encouraged to update to a version newer than 0.1.14 beta-17 is nicely proactive. No complaints here. If policyd-weight doesn't get a maintainer, guess we'll be moving to postfwd. But I tried running that overnight instead, and while it's a very promising framework it seemed not quite as mature yet. Best, Whit Policyd-weight Mailinglist - http://www.policyd-weight.org/
Re: Thanks for fix, Website slightly confused
On Fri, Mar 28, 2008 at 12:34:05PM -0400, Whit Blauvelt wrote: Hi, At the moment policyd-weight Version: 0.1.14 beta-17 links to beta-15, Empty the cache, force a reload. It is 0.1.14 beta-17 for both (beta, devel) versions. You are encouraged to update to a version newer than 0.1.14 beta-17 is nicely proactive. Fixed. Sorry. -- Robert Felber (PGP: 896CF30B) Munich, Germany Policyd-weight Mailinglist - http://www.policyd-weight.org/
Re: Thanks for fix, Website slightly confused
On Fri, Mar 28, 2008 at 12:34:28PM -0400, Whit Blauvelt wrote: No complaints here. If policyd-weight doesn't get a maintainer, guess we'll be moving to postfwd. But I tried running that overnight instead, and while it's a very promising framework it seemed not quite as mature yet. I've been running postfwd for several weeks on production already and it's developing forward very quickly. You can do pretty much everything that policyd-weight does and some better (like async DNS). It's missing some checks like MX relations etc, but I don't know if thats really even needed. The developer is very active and knowable, so I think we are in good shape there. Policyd-weight Mailinglist - http://www.policyd-weight.org/
Re: Thanks for fix, Website slightly confused
Original-Nachricht Datum: Fri, 28 Mar 2008 18:49:12 +0200 Von: Henrik K [EMAIL PROTECTED] An: policyd-weight-list@ek-muc.de Betreff: Re: Thanks for fix, Website slightly confused On Fri, Mar 28, 2008 at 12:34:28PM -0400, Whit Blauvelt wrote: No complaints here. If policyd-weight doesn't get a maintainer, guess we'll be moving to postfwd. But I tried running that overnight instead, and while it's a very promising framework it seemed not quite as mature yet. I've been running postfwd for several weeks on production already and it's developing forward very quickly. You can do pretty much everything that policyd-weight does and some better (like async DNS). It's missing some checks like MX relations etc, but I don't know if thats really even needed. The developer is very active and knowable, so I think we are in good shape there. Care to share your rules for postfwd? Policyd-weight Mailinglist - http://www.policyd-weight.org/ -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.gmx.net/de/entertainment/games/free Policyd-weight Mailinglist - http://www.policyd-weight.org/
Re: security: version update: version 0.1.14 beta-17
On Fri, 28 Mar 2008, Robert Felber wrote: 1st: I assumed [ -L /foo/bar ] is the same as [ -L /foo/bar/ ] because the -L tells the file test what to look for. But in the latter form it is checked with S_IFDIR. If you have a trailing slash, Linux follows the symbolic link and runs lstat on what the link points to, not the link itself. You can demonstrate the same behavior with ls: [EMAIL PROTECTED] ~/tmp $ mkdir foo [EMAIL PROTECTED] ~/tmp $ ln -s foo bar [EMAIL PROTECTED] ~/tmp $ touch foo/baz [EMAIL PROTECTED] ~/tmp $ ls -l bar lrwxrwxrwx 1 henson henson 3 Mar 28 16:21 bar - foo [EMAIL PROTECTED] ~/tmp $ ls -l bar/ total 0-rw-r--r-- 1 henson henson 0 Mar 28 16:21 baz Interestingly, other operating systems display different behavior. For example, under Solaris 8: $ ls -l bar/ lrwxrwxrwx 1 henson csupomona 3 Mar 28 15:20 bar/ - foo I'm not sure which is the more correct behavior... Also, the S_IFDIR output from strace isn't an argument to lstat, it's the return value of the lstat call. 2nd: policyd-weight didn't check the ownership of real directories which might have been resulted in a race attack. Policyd-weight once gets the stat/lstat and reuses that information in order to provide some sort of atomicity of the check_symlnk() sub-routine. There are still race conditions present in the code. It is rather difficult to securely create files/directories in a world writable directory. If you are running on a multiuser system, it's probably best to have the lock directory someplace writable only by the service user. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 Policyd-weight Mailinglist - http://www.policyd-weight.org/
