* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> [...]. This occurs because the bd_release function will
> bd_release(bdev) and set inode->i_security to NULL on the close(fd1).
> Hence, we want to place the control at the level of the file struct,
> not the inode.
This is basically what I was refer
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> On Tue, 08 Feb 2005 11:24:50 CST, Michael Halcrow said:
>
> > While the program is waiting for a keystroke, mount the block device.
> > Enter a keystroke. The result without the patch is 1, which is a
> > security violation. This occurs because th
On Tue, 08 Feb 2005 11:24:50 CST, Michael Halcrow said:
> While the program is waiting for a keystroke, mount the block device.
> Enter a keystroke. The result without the patch is 1, which is a
> security violation. This occurs because the bd_release function will
> bd_release(bdev) and set ino
On Mon, Feb 07, 2005 at 02:26:03PM -0800, Chris Wright wrote:
> * Michael Halcrow ([EMAIL PROTECTED]) wrote:
> > This is the third in a series of eight patches to the BSD Secure
> > Levels LSM. It moves the claim on the block device from the inode
> > struct to the file struct in order to address
>The attack is to hardlink some tempfile name to some file you want
>over-written. This usually involves just a little bit of work, such as
>recognizing that a given root cronjob uses an unsafe predictable filename
>in /tmp (look at the Bugtraq or Full-Disclosure archives, there's plenty).
>Then y
On Mon, 07 Feb 2005 18:20:36 PST, Chris Wright said:
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > open("/tmp/sh-thd-1107848098", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE,
0600) = 3
>
> O_EXCL
>
> > Wow - if my /tmp was on the same partition, and I'd hard-linked that
> > file to /etc/p
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> open("/tmp/sh-thd-1107848098", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE,
> 0600) = 3
O_EXCL
> Wow - if my /tmp was on the same partition, and I'd hard-linked that
> file to /etc/passwd, it would be toast now if root had run it.
So, in fact, it
On Tue, 08 Feb 2005 01:48:40 GMT, David Wagner said:
> How would /etc/passwd get clobbered? Are you thinking that a tmp
> cleaner run by cron might delete /tmp/whatever (i.e., delete the hardlink
> you created above)? But deleting /tmp/whatever is safe; it doesn't affect
> /etc/passwd. I'm gues
>For those systems that have everything on one big partition, you can often
>do stuff like:
>
>ln /etc/passwd /tmp/
>
>and wait for /etc/passwd to get clobbered by a cron job run by root...
How would /etc/passwd get clobbered? Are you thinking that a tmp
cleaner run by cron might delete /tmp/what
On Mon, 07 Feb 2005 14:26:03 PST, Chris Wright said:
> * Michael Halcrow ([EMAIL PROTECTED]) wrote:
> > This is the third in a series of eight patches to the BSD Secure
> > Levels LSM. It moves the claim on the block device from the inode
> > struct to the file struct in order to address a potenti
On Mon, 07 Feb 2005 14:26:03 PST, Chris Wright said:
> Hard links still point to same inode, what's the issue that this
> addresses?
For those systems that have everything on one big partition, you can often
do stuff like:
ln /etc/passwd /tmp/
and wait for /etc/passwd to get clobbered by a cron
* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> This is the third in a series of eight patches to the BSD Secure
> Levels LSM. It moves the claim on the block device from the inode
> struct to the file struct in order to address a potential
> circumvention of the control via hard links to block dev
This is the third in a series of eight patches to the BSD Secure
Levels LSM. It moves the claim on the block device from the inode
struct to the file struct in order to address a potential
circumvention of the control via hard links to block devices. Thanks
to Serge Hallyn for pointing this out.
13 matches
Mail list logo
