hard links create local DoS vulnerability and security problems

hard links create local DoS vulnerability and security problems

[Jakob Lell]

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

Re: hard links create local DoS vulnerability and security problems

[Måns Rullgård]

Jakob Lell <jlell@JakobLell.de> 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
mru@kth.se

Re: hard links create local DoS vulnerability and security problems

[Mike Fedyk]

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/

Re: hard links create local DoS vulnerability and security problems

[Richard B. Johnson]

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.

Re: hard links create local DoS vulnerability and security problems

[Jamie Lokier]

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

aic7xxx loading oops in 2.6.0-test10

[Alexander Nyberg]

[-- Attachment #1: Type: text/plain, Size: 17462 bytes --]

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: dm@uk.sistina.com
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


[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 19763 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET_EMULATE_RTC is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_RELAXED_AML is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_EISA=y
# CONFIG_EISA_VLB_PRIMING is not set
CONFIG_EISA_PCI_EISA=y
CONFIG_EISA_VIRTUAL_ROOT=y
CONFIG_EISA_NAMES=y
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y
CONFIG_IDE_TASKFILE_IO=y

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_REPORT_LUNS=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_PROBE_EISA_VL is not set
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
CONFIG_DM_IOCTL_V4=y

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_IPV6 is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_NETFILTER is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=m

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
CONFIG_ETHERTAP=m
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
CONFIG_ELPLUS=m
# CONFIG_EL16 is not set
CONFIG_EL3=m
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=m
CONFIG_EEPRO100_PIO=y
# CONFIG_E100 is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_UNIX98_PTYS is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# I2C Algorithms
#

#
# I2C Hardware Bus support
#

#
# I2C Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
CONFIG_RTC=m
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=y
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_GAMMA is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB is not set
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
CONFIG_XFS_RT=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
# CONFIG_DEVFS_FS is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_NCP_FS is not set
CONFIG_CODA_FS=m
CONFIG_CODA_FS_OLD_API=y
CONFIG_INTERMEZZO_FS=m
CONFIG_AFS_FS=m
CONFIG_RXRPC=m

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

Re: aic7xxx loading oops in 2.6.0-test10

[Ken Witherow]

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 >

Re: aic7xxx loading oops in 2.6.0-test10

[Ken Witherow]

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

Re: aic7xxx loading oops in 2.6.0-test10

[Dick Streefland]

Ken Witherow <ken@krwtech.com> 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
dick.streefland@xs4all.nl         (@ @)       The Netherlands
------------------------------oOO--(_)--OOo------------------

Re: hard links create local DoS vulnerability and security problems

[Matthias Andree]

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

Re: hard links create local DoS vulnerability and security problems

[Jan Kara]

> 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 <jack@suse.cz>
SuSE CR Labs

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

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

Re: hard links create local DoS vulnerability and security problems

[Rudo Thomas]

> 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.

Re: hard links create local DoS vulnerability and security problems

[Richard B. Johnson]

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\b \b
# 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.

Re: hard links create local DoS vulnerability and security problems

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

[OT] Re: hard links create local DoS vulnerability and security problems

[Rudo Thomas]

> 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.

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

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

Re: hard links create local DoS vulnerability and security problems

[splite]

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.

Re: hard links create local DoS vulnerability and security problems

[Richard B. Johnson]

On Mon, 24 Nov 2003 splite@purdue.edu 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.

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

On Monday 24 November 2003 19:13, Richard B. Johnson wrote:
> On Mon, 24 Nov 2003 splite@purdue.edu 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

Re: hard links create local DoS vulnerability and security problems

[bill davidsen]

In article <Pine.LNX.4.53.0311241312180.18685@chaos>,
Richard B. Johnson <root@chaos.analogic.com> wrote:
| On Mon, 24 Nov 2003 splite@purdue.edu 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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

On Monday 24 November 2003 19:08, splite@purdue.edu 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.

Re: hard links create local DoS vulnerability and security problems

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

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]....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: hard links create local DoS vulnerability and security proble

[Mathieu Chouquet-Stringer]

Valdis.Kletnieks@vt.edu 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 : mathieu@newview.com
       Never attribute to malice that which can be adequately
                    explained by stupidity.
                     -- Hanlon's Razor --

Re: hard links create local DoS vulnerability and security proble

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

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... ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: hard links create local DoS vulnerability and security proble

[Mathieu Chouquet-Stringer]

On Mon, Nov 24, 2003 at 03:00:27PM -0500, Valdis.Kletnieks@vt.edu 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 : mathieu@newview.com
       Never attribute to malice that which can be adequately
                    explained by stupidity.
                     -- Hanlon's Razor --

Re: hard links create local DoS vulnerability and security proble

[H. Peter Anvin]

Followup to:  <xltptfhd0wk.fsf@shookay.newview.com>
By author:    Mathieu Chouquet-Stringer <mathieu@newview.com>
In newsgroup: linux.dev.kernel
> 
> It's always been my understanding that you cannot have suid shell script
> because you could easily change the IFS. Am i wrong? (
> 

Well, sort of.

You can't have a setuid shell script using #!/bin/bash because
/bin/bash doesn't support it.

You *can* have a setuid Perl script using #!/usr/bin/perl because Perl
knows how to run setuid safely.

It's up to the script interpreter (if it is setuid or has an setuid
wrapper available -- Perl does it the latter way) to decide to honour
the setuid bit on a script.

If you really want to use a setuid script, you can create
a setuid /usr/bin/setuidbash which would do whatever sanitization you
felt was appropriate, and then exec bash with the appropriate
permissions.  Then put #!/usr/bin/setuidbash in your scripts.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: hard links create local DoS vulnerability and security problems

[Michael Buesch]

-----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-----

Re: hard links create local DoS vulnerability and security problems

[Jakob Lell]

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

Re: hard links create local DoS vulnerability and security problems

[Chris Wright]

* Michael Buesch (mbuesch@freenet.de) 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

Re: hard links create local DoS vulnerability and security problems

[bill davidsen]

In article <20031124105321.A16684@osdlab.pdx.osdl.net>,
Chris Wright  <chrisw@osdl.org> wrote:
| * Michael Buesch (mbuesch@freenet.de) 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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: hard links create local DoS vulnerability and security problems

[Jesse Pollard]

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).

Re: hard links create local DoS vulnerability and security problems

[bill davidsen]

In article <200311241736.23824.jlell@JakobLell.de>,
Jakob Lell  <jlell@JakobLell.de> 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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: hard links create local DoS vulnerability and security problems

[Mike Fedyk]

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.

Re: hard links create local DoS vulnerability and security problems

[Chris Wright]

* bill davidsen (davidsen@tmr.com) 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

Re: hard links create local DoS vulnerability and security problems

[Amon Ott]

On Dienstag, 25. November 2003 01:35, Chris Wright wrote:
> * bill davidsen (davidsen@tmr.com) 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

Re: hard links create local DoS vulnerability and security problems

[Bill Davidsen]

On Mon, 24 Nov 2003, Chris Wright wrote:

> * bill davidsen (davidsen@tmr.com) 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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: hard links create local DoS vulnerability and security problems

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

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 www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: hard links create local DoS vulnerability and security problems

[Andy Lutomirski]

Valdis.Kletnieks@vt.edu 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

Re: hard links create local DoS vulnerability and security problems

[Linus Torvalds]

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

Re: hard links create local DoS vulnerability and security problems

[Ricky Beam]

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

Re: hard links create local DoS vulnerability and security problems

[John Bradford]

Quote from Andy Lutomirski <luto@myrealbox.com>:
> 
> 
> Valdis.Kletnieks@vt.edu 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.

Re: hard links create local DoS vulnerability and security problems

[Måns Rullgård]

John Bradford <john@grabjohn.com> 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
mru@kth.se

Re: hard links create local DoS vulnerability and security problems

[John Bradford]

Quote from mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> John Bradford <john@grabjohn.com> 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.

Re: hard links create local DoS vulnerability and security problems

[Måns Rullgård]

John Bradford <john@grabjohn.com> 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
mru@kth.se

Re: hard links create local DoS vulnerability and security problems

[John Bradford]

Quote from mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> John Bradford <john@grabjohn.com> 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.