Hello,
on Linux it is possible for any user to create a hard link to a file belonging
to another user. This hard link continues to exist even if the original file
is removed by the owner. However, as the link still belongs to the original
owner, it is still counted to his quota. If a malicious user creates hard
links for every temp file created by another user, this can make the victim
run out of quota (or even fill up the hard disk). This makes a local DoS
attack possible.
Furthermore, users can even create links to a setuid binary. If there is a
security whole like a buffer overflow in any setuid binary, a cracker can
create a hard link to this file in his home directory. This link still exists
when the administrator has fixed the security whole by removing or replacing
the insecure program. This makes it possible for a cracker to keep a security
whole open until an exploit is available. It is even possible to create links
to every setuid program on the system. This doesn't create new security
wholes but makes it more likely that they are exploited.
To solve the problem, the kernel shouldn't allow users to create hard links to
files belonging to someone else.
I could reproduce the problem on linux 2.2.19 and 2.4.21 (and found nothing
about it in the changelogs to 2.4.23-rc3).
Regards
Jakob
Jakob Lell <[email protected]> writes:
> on Linux it is possible for any user to create a hard link to a file
> belonging to another user. This hard link continues to exist even if
> the original file is removed by the owner. However, as the link
> still belongs to the original owner, it is still counted to his
> quota. If a malicious user creates hard links for every temp file
> created by another user, this can make the victim run out of quota
> (or even fill up the hard disk). This makes a local DoS attack
> possible.
This only make for a DoS attack if the there are user-writable
directories on a filesystem that the system depends on being writable.
> Furthermore, users can even create links to a setuid binary. If
> there is a security whole like a buffer overflow in any setuid
> binary, a cracker can create a hard link to this file in his home
> directory. This link still exists when the administrator has fixed
> the security whole by removing or replacing the insecure
> program. This makes it possible for a cracker to keep a security
> whole open until an exploit is available. It is even possible to
> create links to every setuid program on the system. This doesn't
> create new security holes but makes it more likely that they are
> exploited.
If any SUID user writable directories (/tmp, /var/various, /home) are
kept on separate partitions from any SUID executables (belonging in
/bin and /usr/bin), creating such links becomes impossible, and the
problem vanishes.
If a SUID program is found to have a security hole, the administrator
should make sure he removes all links to it when deleting it, just to
be safe.
--
M?ns Rullg?rd
[email protected]
On Mon, 24 Nov 2003, Jakob Lell wrote:
> Hello,
> on Linux it is possible for any user to create a hard link to a file belonging
> to another user. This hard link continues to exist even if the original file
> is removed by the owner. However, as the link still belongs to the original
> owner, it is still counted to his quota. If a malicious user creates hard
> links for every temp file created by another user, this can make the victim
> run out of quota (or even fill up the hard disk). This makes a local DoS
> attack possible.
>
You can create hard-links to any file that a user has given you
permission to read or execute. This is correct. The new hard-link
still belongs to the original user, which is also correct.
To prevent this, a user can set his default permissions so that
neither group nor world can read the files. This is usually done
by setting the attributes in the user's top directory.
> Furthermore, users can even create links to a setuid binary. If there is a
> security whole like a buffer overflow in any setuid binary, a cracker can
> create a hard link to this file in his home directory. This link still exists
> when the administrator has fixed the security whole by removing or replacing
> the insecure program. This makes it possible for a cracker to keep a security
> whole open until an exploit is available. It is even possible to create links
> to every setuid program on the system. This doesn't create new security
> wholes but makes it more likely that they are exploited.
>
A setuid binary created with a hard-link will only work as a setuid
binary if the directory it's in is owned by root. If you have users
that can create files or hard-links within such directories, you
have users who either know the root password already or have used
some exploit to become root. In any case, it's not a hard-link
problem
> To solve the problem, the kernel shouldn't allow users to create hard
> links to
> files belonging to someone else.
>
No. Users must be able to create hard links to files that belong
to somebody else if they are readable. It's a requirement.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Richard B. Johnson wrote:
> To prevent this, a user can set his default permissions so that
> neither group nor world can read the files. This is usually done
> by setting the attributes in the user's top directory.
Correct, but the quota problem is genuine: what if I want to create a
lot of files in /home/jamie that are readable by other users, but I
want to be able to delete them at some later time and reuse my quota
for something else?
This is quite a normal scenario on multi-user systems with quotas.
You seem to be suggesting that the only method is to have a separate
partition for each user, which is absurd.
Another method is "tree quotas" which have come up on this list
before. Hopefully they will be included one day; tree quotas seem
like they would solve this problem and some others.
> A setuid binary created with a hard-link will only work as a setuid
> binary if the directory it's in is owned by root.
That isn't true.
> If you have users that can create files or hard-links within such
> directories, you have users who either know the root password
> already or have used some exploit to become root. In any case, it's
> not a hard-link problem
/tmp is owned by root and anyone can create a hard link in /tmp to
other files, on a system where /tmp doesn't have its own filesystem.
> No. Users must be able to create hard links to files that belong
> to somebody else if they are readable. It's a requirement.
I disagree. The ability to create files and declare that someone else
can't hard link to them would be useful in a multi-user environment.
-- Jamie
> A setuid binary created with a hard-link will only work as a setuid
> binary if the directory it's in is owned by root. [...]
This is not true, just verified it.
Rudo.
Hello
On Monday 24 November 2003 18:14, Richard B. Johnson wrote:
> On Mon, 24 Nov 2003, Jakob Lell wrote:
> > Hello,
> > on Linux it is possible for any user to create a hard link to a file
> > belonging to another user. This hard link continues to exist even if the
> > original file is removed by the owner. However, as the link still belongs
> > to the original owner, it is still counted to his quota. If a malicious
> > user creates hard links for every temp file created by another user, this
> > can make the victim run out of quota (or even fill up the hard disk).
> > This makes a local DoS attack possible.
>
> You can create hard-links to any file that a user has given you
> permission to read or execute. This is correct. The new hard-link
> still belongs to the original user, which is also correct.
No. You need neither read nor execute permission to create a hard link.
>
> To prevent this, a user can set his default permissions so that
> neither group nor world can read the files. This is usually done
> by setting the attributes in the user's top directory.
Even if you needed read or execute permissions to create hard link, this isn't
always possible. Some files have to be world readable.
>
> > Furthermore, users can even create links to a setuid binary. If there is
> > a security whole like a buffer overflow in any setuid binary, a cracker
> > can create a hard link to this file in his home directory. This link
> > still exists when the administrator has fixed the security whole by
> > removing or replacing the insecure program. This makes it possible for a
> > cracker to keep a security whole open until an exploit is available. It
> > is even possible to create links to every setuid program on the system.
> > This doesn't create new security wholes but makes it more likely that
> > they are exploited.
>
> A setuid binary created with a hard-link will only work as a setuid
> binary if the directory it's in is owned by root. If you have users
> that can create files or hard-links within such directories, you
> have users who either know the root password already or have used
> some exploit to become root. In any case, it's not a hard-link
> problem
Setuid-root binaries also work in a home directory.
You can try it by doing this test:
ln /bin/ping $HOME/ping
$HOME/ping localhost
>
> > To solve the problem, the kernel shouldn't allow users to create hard
> > links to
> > files belonging to someone else.
>
> No. Users must be able to create hard links to files that belong
> to somebody else if they are readable. It's a requirement.
If this is REALLY neccessary, it might be possible to prevent hard links to
setuid binaries.
Regards
Jakob
On Mon, 24 Nov 2003 [email protected] wrote:
> On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> > [...]
> > Setuid-root binaries also work in a home directory.
> > You can try it by doing this test:
> > ln /bin/ping $HOME/ping
> > $HOME/ping localhost
> > [...]
>
> That's why you don't put user-writable directories on the root or /usr
> partitions. (For extra points, mount your /tmp and /var/tmp partitions
> nodev,nosuid.) Seriously guys, this is Unix Admin 101, not a major new
> security problem.
>
And if the inode that was referenced in the root-owned directory
was deleted, it would no longer function as setuid root.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Mon, 24 Nov 2003, Rudo Thomas wrote:
> > A setuid binary created with a hard-link will only work as a setuid
> > binary if the directory it's in is owned by root. [...]
>
> This is not true, just verified it.
>
> Rudo.
>
Really? Has your system been hacked?
Script started on Mon Nov 24 12:56:36 2003
# cat xxx.c
#include <stdio.h>
#include <unistd.h>
int main()
{
setuid(0);
setgid(0);
system("whoami");
return 0;
}
# gcc -o /tmp/xxx xxx.c
# cd /tmpo
# chmod 4755 xxx
# su johnson
$ pwd
/tmp
$ ./xxx
root
$ cd ~
$ cp /tmp/xxx .
$ ls -la xxx
-rwxr-xr-x 1 rjohnson guru 4887 Nov 24 12:57 xxx
$ ./xxx
rjohnson
$ chmod 4755 xxx
$ ./xxx
rjohnson
$ rm xxx
$ ln /tmp/xxx xxx
$ ./xxx
rjohnson
You have new mail in /var/spool/mail/root
$ exit
exit
Script done on Mon Nov 24 13:00:08 2003
This clearly shows that once the file exists in a non-root
directory, it will not function as setuid root.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Monday 24 November 2003 19:08, [email protected] wrote:
> On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> > [...]
> > Setuid-root binaries also work in a home directory.
> > You can try it by doing this test:
> > ln /bin/ping $HOME/ping
> > $HOME/ping localhost
> > [...]
>
> That's why you don't put user-writable directories on the root or /usr
> partitions. (For extra points, mount your /tmp and /var/tmp partitions
> nodev,nosuid.) Seriously guys, this is Unix Admin 101, not a major new
> security problem.
Even if you put /usr on a separate partition, users can create a setuid (not
setuid-root) program in their home directory. Other users can create links to
this program in their home directory. Even if this can't be used to become
root, it shouldn't be possible. To prevent this, you have to put every user's
home directory on a separate partition.
On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> [...]
> Setuid-root binaries also work in a home directory.
> You can try it by doing this test:
> ln /bin/ping $HOME/ping
> $HOME/ping localhost
> [...]
That's why you don't put user-writable directories on the root or /usr
partitions. (For extra points, mount your /tmp and /var/tmp partitions
nodev,nosuid.) Seriously guys, this is Unix Admin 101, not a major new
security problem.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 24 November 2003 18:57, Jakob Lell wrote:
> > > To solve the problem, the kernel shouldn't allow users to create hard
> > > links to
> > > files belonging to someone else.
> >
> > No. Users must be able to create hard links to files that belong
> > to somebody else if they are readable. It's a requirement.
>
> If this is REALLY neccessary, it might be possible to prevent hard links to
> setuid binaries.
What about _not_ modifying the mainstream-kernel behaviour,
but adding an option, to make users unable to create such hard-links,
to selinux and/or grsec?
> Regards
> Jakob
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/wkw8oxoigfggmSgRArwLAJ47CAW90QtuEK+PNAlpzDf3ZBmohgCeKaGT
YKUZQRAYYnszq90a34KmH6U=
=EUOO
-----END PGP SIGNATURE-----
On Mon, 24 Nov 2003 13:10:46 EST, "Richard B. Johnson" said:
> # chmod 4755 xxx
> # su johnson
> $ cp /tmp/xxx .
> $ ls -la xxx
> -rwxr-xr-x 1 rjohnson guru 4887 Nov 24 12:57 xxx
^ Hmm.. this sucker is mode 755, not 4755...
> This clearly shows that once the file exists in a non-root
> directory, it will not function as setuid root.
No, what it shows is that once you *copy* the file to another file,
and the second file isn't set-UID, it won't run as set-UID anymore.
On Monday 24 November 2003 19:21, Michael Buesch wrote:
> On Monday 24 November 2003 18:57, Jakob Lell wrote:
> > > > To solve the problem, the kernel shouldn't allow users to create hard
> > > > links to
> > > > files belonging to someone else.
> > >
> > > No. Users must be able to create hard links to files that belong
> > > to somebody else if they are readable. It's a requirement.
> >
> > If this is REALLY neccessary, it might be possible to prevent hard links
> > to setuid binaries.
>
> What about _not_ modifying the mainstream-kernel behaviour,
> but adding an option, to make users unable to create such hard-links,
> to selinux and/or grsec?
Hello,
this would be possible. However, most admins don't install this patches and
thus stay vulnerable. Is there any reason why users should be able to create
hard links to setuid programs belonging to anyone else?
Regards
Jakob
On Monday 24 November 2003 19:13, Richard B. Johnson wrote:
> On Mon, 24 Nov 2003 [email protected] wrote:
> > On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
> > > [...]
> > > Setuid-root binaries also work in a home directory.
> > > You can try it by doing this test:
> > > ln /bin/ping $HOME/ping
> > > $HOME/ping localhost
> > > [...]
> >
> > That's why you don't put user-writable directories on the root or /usr
> > partitions. ?(For extra points, mount your /tmp and /var/tmp partitions
> > nodev,nosuid.) ?Seriously guys, this is Unix Admin 101, not a major new
> > security problem.
>
> And if the inode that was referenced in the root-owned directory
> was deleted, it would no longer function as setuid root.
Hello,
I've just checked it out. It still works as setuid root. Just try this (as
root):
cp /bin/ping /tmp/ping
chmod 4755 /tmp/ping
su user
ln /tmp/ping $HOME/ping
exit
rm /tmp/ping
su user
$HOME/ping localhost
rm $HOME/ping
Regards
Jakob
On Mon, 24 Nov 2003 19:18:56 +0100, Jakob Lell said:
>
> Even if you put /usr on a separate partition, users can create a setuid (not
> setuid-root) program in their home directory. Other users can create links to
> this program in their home directory. Even if this can't be used to become
> root, it shouldn't be possible. To prevent this, you have to put every user's
> home directory on a separate partition.
mkdir ~/bin
chmod 700 ~/bin
cat > ~/bin/show-me
#!/bin/sh
whoami
^D
chmod 4755 ~/bin/show-me
No separate partitions needed.
If the link() syscall doesn't throw an EACCESS because of that chmod,
you have bigger problems.
In any case, if a user is *MAKING* a program set-UID, it's probably because
he *wants* it to run as himself even if others invoke it (otherwise, he
could just leave it in ~/bin and be happy). So this is really a red herring,
as it's only a problem if (a) he decides to get rid of the binary, and fails
to do so because of hard links he doesn't know about, or (b) he's an idiot
programmer and it malfunctions if invoked with an odd argv[0]....
* Michael Buesch ([email protected]) wrote:
> What about _not_ modifying the mainstream-kernel behaviour,
> but adding an option, to make users unable to create such hard-links,
> to selinux and/or grsec?
It's already in grsec and owl. SELinux has the ability to control this
behaviour, just requires the right policy.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This did not happen in 2.6.0-test9-bk15.
I also tried with pci=noacpiand got the same situation.
After the "badness" I get back to my prompt.
I also attached a scsi disk later on which appeared to load fine and did
work. But the same oops is still there.
--
storage:~# modprobe aic7xxx
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.35
<Adaptec 2940 Pro Ultra SCSI adapter>
aic7880: Ultra Wide Channel A, SCSI Id=8, 16/253 SCBs
Badness in kobject_get at lib/kobject.c:439
Call Trace:
[<c0250e5c>] kobject_get+0x4c/0x50
[<c02939d8>] get_device+0x18/0x30
[<c02bb52c>] scsi_device_get+0x2c/0x70
[<c02bb5f2>] __scsi_iterate_devices+0x32/0x60
[<c02becf9>] scsi_run_host_queues+0x19/0x50
[<e08c3bd4>] ahc_linux_release_simq+0x84/0xc0 [aic7xxx]
[<e08bf2f0>] ahc_linux_dv_thread+0x140/0x1b0 [aic7xxx]
[<e08bf1b0>] ahc_linux_dv_thread+0x0/0x1b0 [aic7xxx]
[<c0107049>] kernel_thread_helper+0x5/0xc
--
storage:~# cat /proc/modules
aic7xxx 207788 0 - Live 0xe08a7000
rtc 11768 0 - Live 0xe0864000
ide_cd 40580 0 - Live 0xe0814000
cdrom 34656 1 ide_cd, Live 0xe0820000
--
storage:~# dmesg
Linux version 2.6.0-test10 (root@storage) (gcc version 3.3.2 (Debian))
#1 Mon Nov 24 18:45:56 CET 2003
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131056
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 126960 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 VT8371 ) @
0x000f7890
ACPI: RSDT (v001 VT8371 AWRDACPI 0x42302e31 AWRD 0x00000000) @
0x1fff3000
ACPI: FADT (v001 VT8371 AWRDACPI 0x42302e31 AWRD 0x00000000) @
0x1fff3040
ACPI: DSDT (v001 VT8371 AWRDACPI 0x00001000 MSFT 0x0100000c) @
0x00000000
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=Linux-2.6-10 ro root=301
console=ttyS0,9600 console=tty0
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 1050.212 MHz processor
Console: colour VGA+ 80x25
Memory: 514800k/524224k available (2265k kernel code, 8676k reserved,
615k data, 392k init, 0k highmem)
Calibrating delay loop... 2068.48 BogoMIPS
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183fbff c1c7fbff 00000000
00000000
CPU: After vendor identify, caps: 0183fbff c1c7fbff 00000000
00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0183fbff c1c7fbff 00000000 00000020
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) processor stepping 04
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1049.0942 MHz.
..... host bus clock speed is 199.0989 MHz.
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfb4e0, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031002
spurious 8259A interrupt: IRQ7.
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Disabling VIA memory write queue (PCI ID 0305, rev 03): [55] 89 & 1f ->
09
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even
'acpi=off'
Machine check exception polling timer started.
VFS: Disk quotas dquot_6.5.1
SGI XFS for Linux with ACLs, realtime, no debug enabled
SGI XFS Quota Management subsystem
Initializing Cryptographic API
Applying VIA southbridge workaround.
PCI: Disabling Via external APIC routing
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 32M @ 0xe8000000
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing
disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:pio
hda: SAMSUNG SV2001H, ATA DISK drive
hdb: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 39179952 sectors (20060 MB) w/2048KiB Cache, CHS=38869/16/63,
UDMA(100)
hda: hda1 hda2
mice: PS/2 mouse device common for all mice
input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
device-mapper: 4.0.0-ioctl (2003-06-04) initialised: [email protected]
EISA: Probing bus 0 at eisa0
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 392k freed
EXT3 FS on hda1, internal journal
hdb: ATAPI 52X CD-ROM drive, 192kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 327672k swap on /dev/vg00/swap. Priority:-1 extents:1
--
storage:~# cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 6.2.35
Adaptec 2940 Pro Ultra SCSI adapter
aic7880: Ultra Wide Channel A, SCSI Id=8, 16/253 SCBs
Allocated SCBs: 4, SG List Length: 128
Serial EEPROM:
0xc378 0xc378 0xc378 0xc378 0xc378 0xc378 0xc378 0xc378
0xc378 0xc378 0xc378 0xc378 0xc378 0xc378 0xc378 0xc378
0x18a6 0x045f 0x2808 0x0010 0xffff 0xffff 0xffff 0xffff
0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x7c92
Target 0 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 1 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 2 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 3 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 4 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 5 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 6 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 7 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 8 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 9 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 10 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 11 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 12 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 13 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 14 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
Target 15 Negotiation Settings
User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
--
storage:~# lspci -vvv
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
(rev 03)
Subsystem: ABIT Computer Corp. KT7/KT7-RAID/KT7A/KT7A-RAID
Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 8
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=32M]
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: ea000000-ebffffff
Prefetchable memory behind bridge: e0000000-e7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 40)
Subsystem: ABIT Computer Corp.: Unknown device 0000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc.
VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 4: I/O ports at d000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
40)
Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 11
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC
Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32
bytes)
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at dc00 [size=128]
Region 1: Memory at ed000000 (32-bit, non-prefetchable)
[size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00:11.0 SCSI storage controller: Adaptec AHA-2940UW Pro / AIC-788x (rev
01)
Subsystem: Adaptec 2940UW Pro Ultra-Wide SCSI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 2000ns max), Cache Line Size: 0x08 (32
bytes)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e000 [disabled] [size=256]
Region 1: Memory at ed001000 (32-bit, non-prefetchable)
[size=4K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2
GTS/Pro] (rev a3) (prog-if 00 [VGA])
Subsystem: LeadTek Research Inc. WinFast GeForce2 GTS with TV
output
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ea000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
Rate=<none>
--
storage:~# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000cc000-000cc7ff : Extension ROM
000cd000-000cd7ff : Extension ROM
000f0000-000fffff : System ROM
00100000-1ffeffff : System RAM
00100000-00336621 : Kernel code
00336622-003d053f : Kernel data
1fff0000-1fff2fff : ACPI Non-volatile Storage
1fff3000-1fffffff : ACPI Tables
e0000000-e7ffffff : PCI Bus #01
e0000000-e7ffffff : 0000:01:00.0
e8000000-e9ffffff : 0000:00:00.0
ea000000-ebffffff : PCI Bus #01
ea000000-eaffffff : 0000:01:00.0
ed000000-ed00007f : 0000:00:0d.0
ed001000-ed001fff : 0000:00:11.0
ed001000-ed001fff : aic7xxx
ffff0000-ffffffff : reserved
--
storage:~# cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
5000-500f : 0000:00:07.4
6000-607f : 0000:00:07.4
d000-d00f : 0000:00:07.1
d000-d007 : ide0
d008-d00f : ide1
dc00-dc7f : 0000:00:0d.0
dc00-dc7f : 0000:00:0d.0
e000-e0ff : 0000:00:11.0
[email protected] writes:
> mkdir ~/bin
> chmod 700 ~/bin
> cat > ~/bin/show-me
> #!/bin/sh
> whoami
> ^D
> chmod 4755 ~/bin/show-me
>
> No separate partitions needed.
It's always been my understanding that you cannot have suid shell script
because you could easily change the IFS. Am i wrong? (
--
Mathieu Chouquet-Stringer E-Mail : [email protected]
Never attribute to malice that which can be adequately
explained by stupidity.
-- Hanlon's Razor --
possibly related, I hang on boot when it's time to scan my 2940U2W. No
errors are displayed and keyboard is locked out. Below is what I see in
test9 with a note of where it hangs. I see the drives attached to the
controller flash their access light prior to the hang.
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: IO 0x1800-0x180F, IRQ 0x11
Vendor: ARCHIVE Model: 4326XX 27871-XXX Rev: 0316
Type: Sequential-Access ANSI SCSI revision: 02
Vendor: SEAGATE Model: SX410800N Rev: 7117
Type: Direct-Access ANSI SCSI revision: 02
***hangs here***
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.35
<Adaptec 2940 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
(scsi1:A:0): 20.000MB/s transfers (20.000MHz, offset 31)
(scsi1:A:1): 20.000MB/s transfers (20.000MHz, offset 31)
(scsi1:A:2): 20.000MB/s transfers (20.000MHz, offset 8)
(scsi1:A:6): 10.000MB/s transfers (10.000MHz, offset 8)
(scsi1:A:14): 80.000MB/s transfers (40.000MHz, offset 15, 16bit)
Vendor: IBM Model: DNES-309170 Rev: SAH0
Type: Direct-Access ANSI SCSI revision: 03
scsi1:A:0:0: Tagged Queuing enabled. Depth 32
Vendor: WDIGTL Model: WD183 ULTRA2 Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 02
scsi1:A:1:0: Tagged Queuing enabled. Depth 32
Vendor: TEAC Model: CD-W512SB Rev: 1.0C
Type: CD-ROM ANSI SCSI revision: 02
Vendor: CyberDrv Model: CD-ROM TW240S Rev: 1.20
Type: CD-ROM ANSI SCSI revision: 02
Vendor: SEAGATE Model: SX118273LC Rev: 6367
Type: Direct-Access ANSI SCSI revision: 02
scsi1:A:14:0: Tagged Queuing enabled. Depth 32
st: Version 20030811, fixed bufsize 32768, s/g segs 256
Attached scsi tape st0 at scsi0, channel 0, id 4, lun 0
st0: try direct i/o: yes, max page reachable by HBA 1048575
SCSI device sda: 17096357 512-byte hdwr sectors (8753 MB)
SCSI device sda: drive cache: write through
sda: sda1 sda4 < sda5 >
On Mon, Nov 24, 2003 at 03:00:27PM -0500, [email protected] wrote:
> (And yes, I did it intentionally - figuring that at least one user on
> the list would actually do it and leave a set-UID something lying around
> to shoot themselves in the foot with, so weaponry loaded with blanks
> seemed a good idea... ;)
Ok, just wanted to be sure.
--
Mathieu Chouquet-Stringer E-Mail : [email protected]
Never attribute to malice that which can be adequately
explained by stupidity.
-- Hanlon's Razor --
On Mon, 24 Nov 2003 14:25:31 EST, Mathieu Chouquet-Stringer said:
> It's always been my understanding that you cannot have suid shell script
> because you could easily change the IFS. Am i wrong? (
IFS is just one of the *many* issues (there's also a ton of race conditions
caused by #! handling, among other things).
You don't like the shell script, feel free to substitude in the C-language
equivalent that was posted previously :)
(And yes, I did it intentionally - figuring that at least one user on the
list would actually do it and leave a set-UID something lying around to
shoot themselves in the foot with, so weaponry loaded with blanks seemed a
good idea... ;)
On Mon, Nov 24, 2003 at 06:05:53PM +0100, M?ns Rullg?rd wrote:
> If a SUID program is found to have a security hole, the administrator
> should make sure he removes all links to it when deleting it, just to
> be safe.
or in the common case:
s/administrator/package manager/
On Mon, 24 Nov 2003, Burton Windle wrote:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106965748506343&w=2
>
> This one-liner fixed my hang-on-boot with my AIC7880.
This patch does indeed fix the hang for me
--
Ken Witherow <phantoml AT rochester.rr.com>
ICQ: 21840670 AIM: phantomlordken
http://www.krwtech.com/ken
[email protected] wrote:
>
> In any case, if a user is *MAKING* a program set-UID, it's probably because
> he *wants* it to run as himself even if others invoke it (otherwise, he
> could just leave it in ~/bin and be happy). So this is really a red herring,
> as it's only a problem if (a) he decides to get rid of the binary, and fails
> to do so because of hard links he doesn't know about, or (b) he's an idiot
> programmer and it malfunctions if invoked with an odd argv[0]....
Right... but non-privileged users _can't_ delete these extra links, even
if they notice them from the link count. And non-idiots do make
security errors -- they just fix them. But in this case, fixing the
error after the fact may be impossible without root's help.
And how many package managers / install scripts check for hard links of
files they're about to overwrite?
--Andy
On Mon, 24 Nov 2003, Andy Lutomirski wrote:
>
> Right... but non-privileged users _can't_ delete these extra links, even
> if they notice them from the link count. And non-idiots do make
> security errors -- they just fix them. But in this case, fixing the
> error after the fact may be impossible without root's help.
Just do
chmod ug-s file
and you're done.
If you delete the file first, you'll need roots help, but hey, be careful.
Linus
Quote from Andy Lutomirski <[email protected]>:
>
>
> [email protected] wrote:
>
> >
> > In any case, if a user is *MAKING* a program set-UID, it's probably because
> > he *wants* it to run as himself even if others invoke it (otherwise, he
> > could just leave it in ~/bin and be happy). So this is really a red herring,
> > as it's only a problem if (a) he decides to get rid of the binary, and fails
> > to do so because of hard links he doesn't know about, or (b) he's an idiot
> > programmer and it malfunctions if invoked with an odd argv[0]....
>
> Right... but non-privileged users _can't_ delete these extra links, even
> if they notice them from the link count.
They can truncate the file to zero length, though, then delete the
'original' link, making all of the other links point to the zero
length file.
John.
> Really? Has your system been hacked?
Nope. However, I use vanilla 2.4 kernel series. You seem to run something more
restrictive, as the example you have posted does the expected thing on my
system. (Prints root, rjohnson, root.)
Bye.
Rudo.
John Bradford <[email protected]> writes:
>> Right... but non-privileged users _can't_ delete these extra links, even
>> if they notice them from the link count.
>
> They can truncate the file to zero length, though, then delete the
> 'original' link, making all of the other links point to the zero
> length file.
It could be tricky to find those extra links if the original has been
deleted, of course.
--
M?ns Rullg?rd
[email protected]
On Mon, 24 Nov 2003, Linus Torvalds wrote:
>Just do
>
> chmod ug-s file
>
>and you're done.
>
>If you delete the file first, you'll need roots help, but hey, be careful.
Heh, thus enters paranoia... patern fill the file (zero's will do), truncate,
'chmod 0', and *then* unlink it. Yeah, it's eating up an inode charged to
the user, but otherwise, no space and the contents are gone.
--Ricky
Ken Witherow <[email protected]> wrote:
| On Mon, 24 Nov 2003, Burton Windle wrote:
|
| > http://marc.theaimsgroup.com/?l=linux-scsi&m=106965748506343&w=2
| >
| > This one-liner fixed my hang-on-boot with my AIC7880.
|
| This patch does indeed fix the hang for me
I can confirm that. My 2.6.0-test10 kernel was hanging between the IDE
and SCSI probes:
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2: I/O resource 0x3EE-0x3EE not free.
ide2: ports already in use, skipping probe
hda: max request size: 128KiB
hda: 25429824 sectors (13020 MB) w/418KiB Cache, CHS=25228/16/63, UDMA(33)
hda: hda1 hda2 hda3 hda4
hdb: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
PCI: Enabling device 0000:00:14.0 (0000 -> 0003)
*** hang ***
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.35
<Adaptec aic7890/91 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
The patch fixes the hang, but causes another problem:
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.35
<Adaptec aic7890/91 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
(scsi0:A:3): 10.000MB/s transfers (10.000MHz, offset 15)
Badness in kobject_get at /work/kernel/linux-2.6.0-test10/lib/kobject.c:439
Call Trace:
[kobject_get+80/96] kobject_get+0x50/0x60
[get_device+24/32] get_device+0x18/0x20
[scsi_device_get+44/128] scsi_device_get+0x2c/0x80
[__scsi_iterate_devices+75/128] __scsi_iterate_devices+0x4b/0x80
[scsi_run_host_queues+23/80] scsi_run_host_queues+0x17/0x50
[ahc_linux_release_simq+148/208] ahc_linux_release_simq+0x94/0xd0
[ahc_linux_dv_thread+506/592] ahc_linux_dv_thread+0x1fa/0x250
[ahc_linux_dv_thread+0/592] ahc_linux_dv_thread+0x0/0x250
[kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
Vendor: YAMAHA Model: CRW6416S Rev: 1.0b
Type: CD-ROM ANSI SCSI revision: 02
Vendor: ARCHIVE Model: VIPER 150 21247 Rev: -005
Type: Sequential-Access ANSI SCSI revision: 01
The following patch seems to fix this second problem:
http://marc.theaimsgroup.com/?l=linux-scsi&m=106940008217622&w=2
--
Dick Streefland //// De Bilt
[email protected] (@ @) The Netherlands
------------------------------oOO--(_)--OOo------------------
In article <[email protected]>,
Jakob Lell <[email protected]> wrote:
| on Linux it is possible for any user to create a hard link to a file belonging
| to another user. This hard link continues to exist even if the original file
| is removed by the owner. However, as the link still belongs to the original
| owner, it is still counted to his quota. If a malicious user creates hard
| links for every temp file created by another user, this can make the victim
| run out of quota (or even fill up the hard disk). This makes a local DoS
| attack possible.
Of course they must be created in a directory when the evil user has
write, from a directory where the evil user has... have to check if
that's read or just evecute.
|
| Furthermore, users can even create links to a setuid binary. If there is a
| security whole like a buffer overflow in any setuid binary, a cracker can
| create a hard link to this file in his home directory.
Not unless the admin is a total bozo... remember hard links must be in
the same filesystem, and I wouldn't expect untrusted users to have write
in /usr, /var, /lib or /opt, which is where the problem might likely to
exist.
| This link still exists
| when the administrator has fixed the security whole by removing or replacing
| the insecure program. This makes it possible for a cracker to keep a security
| whole open until an exploit is available. It is even possible to create links
| to every setuid program on the system. This doesn't create new security
| wholes but makes it more likely that they are exploited.
See above, this is less likely that you make it sound.
|
| To solve the problem, the kernel shouldn't allow users to create hard links to
| files belonging to someone else.
While I think you're overblowing the problem, it is an issue which might
be addressed in SE Linux or somewhere. I have an idea on that, but I
want to look before I suggest anything.
|
| I could reproduce the problem on linux 2.2.19 and 2.4.21 (and found nothing
| about it in the changelogs to 2.4.23-rc3).
Bear in mind it isn't a "problem" it's 'expected behaviour" for the o/s,
and might even be mentioned in SuS somehow. Interesting topic, but not a
bug, since the behaviour is as intended.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
In article <Pine.LNX.4.53.0311241312180.18685@chaos>,
Richard B. Johnson <[email protected]> wrote:
| On Mon, 24 Nov 2003 [email protected] wrote:
|
| > On Mon, Nov 24, 2003 at 06:57:41PM +0100, Jakob Lell wrote:
| > > [...]
| > > Setuid-root binaries also work in a home directory.
| > > You can try it by doing this test:
| > > ln /bin/ping $HOME/ping
| > > $HOME/ping localhost
| > > [...]
| >
| > That's why you don't put user-writable directories on the root or /usr
| > partitions. (For extra points, mount your /tmp and /var/tmp partitions
| > nodev,nosuid.) Seriously guys, this is Unix Admin 101, not a major new
| > security problem.
| >
|
| And if the inode that was referenced in the root-owned directory
| was deleted, it would no longer function as setuid root.
??? think about how the inode is deleted... by removing all links.
Clearly if there is another link the inode can't be deleted, and if the
inode is deleted whatever you meant by "it" would function or even exist
(both the link and the inode would be gone).
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
In article <[email protected]>,
Chris Wright <[email protected]> wrote:
| * Michael Buesch ([email protected]) wrote:
| > What about _not_ modifying the mainstream-kernel behaviour,
| > but adding an option, to make users unable to create such hard-links,
| > to selinux and/or grsec?
|
| It's already in grsec and owl. SELinux has the ability to control this
| behaviour, just requires the right policy.
Bah!! I just spent 20 minutes deciding that I could add an attribute to
a file which prevented hard links, and similar to a directory. OTOH you
saved me the work of doing more than a few lines on paper, and it's
reassuring to know the security patches are ahead of the problem.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, Nov 24, 2003 at 11:50:12PM +0000, Bill Davidsen wrote:
> While I think you're overblowing the problem, it is an issue which might
> be addressed in SE Linux or somewhere. I have an idea on that, but I
> want to look before I suggest anything.
Other posts in this thread confirm that se-linux is able to do this if
configured correctly, and is an option in grsec.
* bill davidsen ([email protected]) wrote:
>
> While I think you're overblowing the problem, it is an issue which might
> be addressed in SE Linux or somewhere. I have an idea on that, but I
> want to look before I suggest anything.
SELinux controls hard link creation by checking, among other things,
the security context of the process attempting the link, and the security
context of the target (oldpath). Other MAC systems do similar, and some
patches such as grsec and owl simply disable linking to files the user
can't read/write to for example.
> Bear in mind it isn't a "problem" it's 'expected behaviour" for the o/s,
> and might even be mentioned in SuS somehow. Interesting topic, but not a
> bug, since the behaviour is as intended.
SuS states:
The implementation may require that the calling process has
permission to access the existing file.
Note the use of *may*.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Mon, 24 Nov 2003, Jamie Lokier wrote:
> You seem to be suggesting that the only method is to have a separate
> partition for each user, which is absurd.
In a previous life, I've seen this happen on a Solaris box, where each
user's home directory was auto-mounted. I haven't tried to betray quotas
at that time though.
> /tmp is owned by root and anyone can create a hard link in /tmp to
> other files, on a system where /tmp doesn't have its own filesystem.
Convert /tmp to swap, mount -t tmpfs :-)
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
On Dienstag, 25. November 2003 01:35, Chris Wright wrote:
> * bill davidsen ([email protected]) wrote:
> >
> > While I think you're overblowing the problem, it is an issue which might
> > be addressed in SE Linux or somewhere. I have an idea on that, but I
> > want to look before I suggest anything.
>
> SELinux controls hard link creation by checking, among other things,
> the security context of the process attempting the link, and the security
> context of the target (oldpath). Other MAC systems do similar, and some
> patches such as grsec and owl simply disable linking to files the user
> can't read/write to for example.
..and in RSBAC, LINK_HARD has been a controlled separate type of access since
the very first version back in 1997. It has always been treated like a write
access to the target file by all decision modules, because of the
implications mentioned in this thread.
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
On Mon, 2003-11-24 at 17:36, Jakob Lell wrote:
> To solve the problem, the kernel shouldn't allow users to create hard links to
> files belonging to someone else.
chmod(fn, 0);
truncate(fn, 0);
unlink(fn);
then just the inode remains.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
Quote from [email protected] (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> John Bradford <[email protected]> writes:
>
> >> Right... but non-privileged users _can't_ delete these extra links, =
> even=20
> >> if they notice them from the link count.
> >
> > They can truncate the file to zero length, though, then delete the
> > 'original' link, making all of the other links point to the zero
> > length file.
>
> It could be tricky to find those extra links if the original has been
> deleted, of course.
True, but as long as at least one of the links which has been made to
the original file is in a directory you have access to, you can simply
create a new link to the file, truncate it, then delete your newly
created link, so actually deleting the 'original' link is not
necessarily a problem :-).
John.
John Bradford <[email protected]> writes:
>> > They can truncate the file to zero length, though, then delete the
>> > 'original' link, making all of the other links point to the zero
>> > length file.
>>
>> It could be tricky to find those extra links if the original has been
>> deleted, of course.
>
> True, but as long as at least one of the links which has been made to
> the original file is in a directory you have access to, you can simply
> create a new link to the file, truncate it, then delete your newly
> created link, so actually deleting the 'original' link is not
> necessarily a problem :-).
There's no need to make a new link, since any links will be owned by
the original owner. That was the concern in the first place. The
problem is finding a link after the file has been deleted. It could
be hidden away somewhere in a directory you don't have read or execute
permission for.
--
M?ns Rullg?rd
[email protected]
Quote from [email protected] (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> John Bradford <[email protected]> writes:
>
> >> > They can truncate the file to zero length, though, then delete the
> >> > 'original' link, making all of the other links point to the zero
> >> > length file.
> >>=20
> >> It could be tricky to find those extra links if the original has bee=
> n
> >> deleted, of course.
> >
> > True, but as long as at least one of the links which has been made to
> > the original file is in a directory you have access to, you can simpl=
> y
> > create a new link to the file, truncate it, then delete your newly
> > created link, so actually deleting the 'original' link is not
> > necessarily a problem :-).
>
> There's no need to make a new link, since any links will be owned by
> the original owner. That was the concern in the first place. The
> problem is finding a link after the file has been deleted. It could
> be hidden away somewhere in a directory you don't have read or execute
> permission for.
Ah, OK, I was thinking of something else entirely :-)
John.
On Monday 24 November 2003 11:57, Jakob Lell wrote:
> Hello
>
> On Monday 24 November 2003 18:14, Richard B. Johnson wrote:
> > On Mon, 24 Nov 2003, Jakob Lell wrote:
> > > Hello,
> > > on Linux it is possible for any user to create a hard link to a file
> > > belonging to another user. This hard link continues to exist even if
> > > the original file is removed by the owner. However, as the link still
> > > belongs to the original owner, it is still counted to his quota. If a
> > > malicious user creates hard links for every temp file created by
> > > another user, this can make the victim run out of quota (or even fill
> > > up the hard disk). This makes a local DoS attack possible.
[snip]
> >
> > A setuid binary created with a hard-link will only work as a setuid
> > binary if the directory it's in is owned by root. If you have users
> > that can create files or hard-links within such directories, you
> > have users who either know the root password already or have used
> > some exploit to become root. In any case, it's not a hard-link
> > problem
>
> Setuid-root binaries also work in a home directory.
> You can try it by doing this test:
> ln /bin/ping $HOME/ping
> $HOME/ping localhost
What? You allow users write access to a filesystem containing privileged
applications????
You really shouldn't do that. Any filesystem a user has write access to should
be mounted nosgid.
> > > To solve the problem, the kernel shouldn't allow users to create hard
> > > links to
> > > files belonging to someone else.
> >
> > No. Users must be able to create hard links to files that belong
> > to somebody else if they are readable. It's a requirement.
>
> If this is REALLY neccessary, it might be possible to prevent hard links to
> setuid binaries.
> Regards
> Jakob
You would also have to consider setgid binaries.
It also means that you have to read the inode of the source file. Right now,
only the contents of directory have to be read (the file search for the inode
number).
> Richard B. Johnson wrote:
> > To prevent this, a user can set his default permissions so that
> > neither group nor world can read the files. This is usually done
> > by setting the attributes in the user's top directory.
>
> Correct, but the quota problem is genuine: what if I want to create a
> lot of files in /home/jamie that are readable by other users, but I
> want to be able to delete them at some later time and reuse my quota
> for something else?
>
> This is quite a normal scenario on multi-user systems with quotas.
>
> You seem to be suggesting that the only method is to have a separate
> partition for each user, which is absurd.
I agree that malicious user can make some user run out of quotas
(actually he can do it even by more secret way by just opening the files
- but for this at least read permission is needed). But I guess that
reasonably capable admin discovers the problem and /bin/nologin as a
login shell solves the problem...
> Another method is "tree quotas" which have come up on this list
> before. Hopefully they will be included one day; tree quotas seem
> like they would solve this problem and some others.
Yes they would but denying hardlinks across 'quota trees' seems to be
the easiest way of making them technically possible and so you end up in
a similar situation as with some security patches...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
On Tuesday 25 November 2003 15:48, Jan Kara wrote:
> > Richard B. Johnson wrote:
> > > To prevent this, a user can set his default permissions so that
> > > neither group nor world can read the files. This is usually done
> > > by setting the attributes in the user's top directory.
> >
> > Correct, but the quota problem is genuine: what if I want to create a
> > lot of files in /home/jamie that are readable by other users, but I
> > want to be able to delete them at some later time and reuse my quota
> > for something else?
> >
> > This is quite a normal scenario on multi-user systems with quotas.
> >
> > You seem to be suggesting that the only method is to have a separate
> > partition for each user, which is absurd.
>
> I agree that malicious user can make some user run out of quotas
> (actually he can do it even by more secret way by just opening the files
> - but for this at least read permission is needed). But I guess that
> reasonably capable admin discovers the problem and /bin/nologin as a
> login shell solves the problem...
Hello,
if it's a web server with thousands of users (and maybe millions of files
in /home), searching /home for files belonging to one user can take quite
long (maybe hours).
If the evil users can't create hard links and thus has to keep the file open
instead of creating a hard link, the problem can quickly be found using lsof.
>
> > Another method is "tree quotas" which have come up on this list
> > before. Hopefully they will be included one day; tree quotas seem
> > like they would solve this problem and some others.
>
> Yes they would but denying hardlinks across 'quota trees' seems to be
> the easiest way of making them technically possible and so you end up in
> a similar situation as with some security patches...
This would also be a good way to fix the problem.
>
> Honza
Regards
Jakob
On Mon, 24 Nov 2003, Chris Wright wrote:
> * bill davidsen ([email protected]) wrote:
> >
> > While I think you're overblowing the problem, it is an issue which might
> > be addressed in SE Linux or somewhere. I have an idea on that, but I
> > want to look before I suggest anything.
>
> SELinux controls hard link creation by checking, among other things,
> the security context of the process attempting the link, and the security
> context of the target (oldpath). Other MAC systems do similar, and some
> patches such as grsec and owl simply disable linking to files the user
> can't read/write to for example.
>
> > Bear in mind it isn't a "problem" it's 'expected behaviour" for the o/s,
> > and might even be mentioned in SuS somehow. Interesting topic, but not a
> > bug, since the behaviour is as intended.
>
> SuS states:
>
> The implementation may require that the calling process has
> permission to access the existing file.
>
> Note the use of *may*.
I note the "permission to access" as well, that's not exactly definitive,
either. Could mean anything from rwx on the file to execute on the file
and all directories in the path. And a conforming o/s could demand that
the process doing the link have the same EUID as the UID of the file. I
would expect that to break things, however, although the things which
break may not be desirable!
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.