From jens at kasten-edv.de Sun Nov 6 13:17:45 2011 From: jens at kasten-edv.de (Jens Kasten) Date: Sun, 06 Nov 2011 13:17:45 +0100 Subject: [rsbac] udev Message-ID: <1320581865.23167.6.camel@malo.jaschtschik.local> Hi list, i use the latest git kernel with pax patch. (3.0.8) When i boot, i see a warning which is append. As next is the udevd could not touch anymore. If udev would be killed or restart the system freeze. This is only on a system when using an encrypted with LVM + ext4. Gr??e Jens -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : warning Dateityp : text/x-vhdl Dateigr??e : 4120 bytes Beschreibung: nicht verf?gbar URL : From tazok.id0 at gmail.com Mon Nov 7 20:03:01 2011 From: tazok.id0 at gmail.com (=?ISO-8859-1?Q?Javier_Juan_Mart=EDnez_Cabez=F3n?=) Date: Mon, 7 Nov 2011 20:03:01 +0100 Subject: [rsbac] port specification under SCD_IOPORTS Message-ID: I make this suggestion that I get realized after this thread from gentoo hardened: http://archives.gentoo.org/gentoo-hardened/msg_8160a0d4bb4e2a0cf09f91c06ded7001.xml I think if it could be, specify under SCD_IOPORTS which port is permited to do iopl/ioperm request, something like AUTH makes with UIDs, since some software would require to only do privilege I/O port against one particular port and no to everyone. It's another less privilege approach that would be useful for example with propietary nvidia drivers that still using priv I/O ports to do his tasks. From ao at rsbac.org Tue Nov 8 09:20:35 2011 From: ao at rsbac.org (Amon Ott) Date: Tue, 8 Nov 2011 09:20:35 +0100 Subject: [rsbac] port specification under SCD_IOPORTS In-Reply-To: References: Message-ID: <201111080920.36100.ao@rsbac.org> On Monday 07 November 2011 wrote Javier Juan Mart?nez Cabez?n: > I make this suggestion that I get realized after this thread from gentoo > hardened: > > http://archives.gentoo.org/gentoo-hardened/msg_8160a0d4bb4e2a0cf09f91c06ded >7001.xml > > I think if it could be, specify under SCD_IOPORTS which port is permited > to do iopl/ioperm request, something like AUTH makes with UIDs, since some > software would require to only do privilege I/O port against one particular > port and no to everyone. It's another less privilege approach that would be > useful for example with propietary nvidia drivers that still using priv I/O > ports to do his tasks. Yes, this does make sense. I would either make it a new target type T_IOPORTS or use a special device major and the port address as minor. It does not fit into T_SCD then, though. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 From ao at rsbac.org Tue Nov 8 09:23:46 2011 From: ao at rsbac.org (Amon Ott) Date: Tue, 8 Nov 2011 09:23:46 +0100 Subject: [rsbac] udev In-Reply-To: <1320581865.23167.6.camel@malo.jaschtschik.local> References: <1320581865.23167.6.camel@malo.jaschtschik.local> Message-ID: <201111080923.46489.ao@rsbac.org> On Sunday 06 November 2011 wrote Jens Kasten: > Hi list, > > i use the latest git kernel with pax patch. (3.0.8) > > When i boot, i see a warning which is append. I have seen this warning, too, but not fixed it yet. The reason is that with RSBAC a normally fast function gets significantly slower - but this function gets only called quite seldom. > As next is the udevd could not touch anymore. > If udev would be killed or restart the system freeze. > > This is only on a system when using an encrypted with LVM + ext4. Please retry with an older udev, if you can. We had similar problems with new udev. Will need some looking into. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 From jens at kasten-edv.de Tue Nov 8 12:11:46 2011 From: jens at kasten-edv.de (Jens Kasten) Date: Tue, 08 Nov 2011 12:11:46 +0100 Subject: [rsbac] udev In-Reply-To: <201111080923.46489.ao@rsbac.org> References: <1320581865.23167.6.camel@malo.jaschtschik.local> <201111080923.46489.ao@rsbac.org> Message-ID: <1320750706.9288.2.camel@malo.jaschtschik.local> Hi Amon, i try this to downgrad udev in my test machine. On attachment is the output. Could it possible that the device-mapper have to downgrade too? Gr??e Jens Am Dienstag, den 08.11.2011, 09:23 +0100 schrieb Amon Ott: > On Sunday 06 November 2011 wrote Jens Kasten: > > Hi list, > > > > i use the latest git kernel with pax patch. (3.0.8) > > > > When i boot, i see a warning which is append. > > I have seen this warning, too, but not fixed it yet. The reason is that with > RSBAC a normally fast function gets significantly slower - but this function > gets only called quite seldom. > > > As next is the udevd could not touch anymore. > > If udev would be killed or restart the system freeze. > > > > This is only on a system when using an encrypted with LVM + ext4. > > Please retry with an older udev, if you can. We had similar problems with new > udev. Will need some looking into. > > Amon. -------------- n?chster Teil -------------- 2 logical volume(s) in volume group "rsbac" now active cryptsetup: vda5_crypt set up successfully done. Begin: Running /scripts/local-premount ... done. [ 15.938836] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) [ 15.960468] rsbac_do_init(): Initializing RSBAC 1.4.6 [ 16.104924] ------------[ cut here ]------------ [ 16.108321] WARNING: at fs/namei.c:1907 rsbac_lookup_one_len+0xe2/0x100() [ 16.127083] Hardware name: Bochs [ 16.140564] Modules linked in: [last unloaded: scsi_wait_scan] [ 16.161935] Pid: 340, comm: exe Not tainted 3.0.8-rsbac-vm5+ #6 [ 16.188076] Call Trace: [ 16.200681] [<000b5b28>] ? warn_slowpath_common+0x78/0xb0 [ 16.222886] [<0014f7a2>] ? rsbac_lookup_one_len+0xe2/0x100 [ 16.246909] [<0014f7a2>] ? rsbac_lookup_one_len+0xe2/0x100 [ 16.266103] [<000b5b7b>] ? warn_slowpath_null+0x1b/0x20 [ 16.290416] [<0014f7a2>] ? rsbac_lookup_one_len+0xe2/0x100 [ 16.311044] [<00052e92>] ? lookup_aci_path_dentry+0x1a2/0x610 [ 16.331259] [<000477e1>] ? rsbac_get_vfsmount+0x51/0xb0 [ 16.349717] [<0005333c>] ? rsbac_read_open+0x3c/0x330 [ 16.368103] [<001329d7>] ? __kmalloc+0x117/0x160 [ 16.384387] [<00011200>] ? intel_pmu_enable_all+0xe0/0x130 [ 16.403687] [<000642ff>] ? do_read_list+0x2f/0x840 [ 16.421937] [<00064319>] ? do_read_list+0x49/0x840 [ 16.438791] [<00011200>] ? intel_pmu_enable_all+0xe0/0x130 [ 16.458432] [<0001ce21>] ? IO_APIC_get_PCI_irq_vector+0x71/0x1d0 [ 16.479625] [<00105d10>] ? zone_watermark_ok+0x30/0x40 [ 16.497508] [<0001ce21>] ? IO_APIC_get_PCI_irq_vector+0x71/0x1d0 [ 16.519679] [<000212d0>] ? hpet_setup_msi_irq+0x20/0x30 [ 16.538834] [<00064b5c>] ? read_list+0x4c/0x140 [ 16.554671] [<00108b94>] ? __alloc_pages_nodemask+0x104/0x730 [ 16.575539] [<000212d0>] ? hpet_setup_msi_irq+0x20/0x30 [ 16.593907] [<0001ce21>] ? IO_APIC_get_PCI_irq_vector+0x71/0x1d0 [ 16.615725] [<000212d0>] ? hpet_setup_msi_irq+0x20/0x30 [ 16.634513] [<001319cc>] ? new_slab+0x13c/0x1e0 [ 16.650090] [<00064f04>] ? rsbac_list_register_hashed+0x2b4/0x860 [ 16.671507] [<001329c1>] ? __kmalloc+0x101/0x160 [ 16.688512] [<000605c9>] ? lookup_reg_name+0x59/0xf0 [ 16.706233] [<00065097>] ? rsbac_list_register_hashed+0x447/0x860 [ 16.727483] [<0006513f>] ? rsbac_list_register_hashed+0x4ef/0x860 [ 16.749234] [<000b1d0a>] ? try_to_wake_up+0x17a/0x200 [ 16.766437] [<0003ea00>] ? debug_adf_default_setup+0x10/0x10 [ 16.786350] [<000a8b47>] ? __wake_up_common+0x47/0x70 [ 16.803575] [<002137c8>] ? number+0x348/0x360 [ 16.842590] [<0008ffff>] ? dazuko_should_scan+0x6f/0x230 [ 16.860652] [<002e0a0a>] ? netlink_broadcast_filtered+0x14a/0x420 [ 16.882264] [<0020d8ac>] ? idr_get_empty_slot+0xfc/0x280 [ 16.902063] [<000236a5>] ? default_spin_lock_flags+0x5/0x10 [ 16.922816] [<003511b7>] ? _raw_spin_lock_irqsave+0x27/0x40 [ 16.942712] [<0020db39>] ? ida_get_new_above+0x109/0x1c0 [ 16.961739] [<002141d1>] ? format_decode+0x321/0x390 [ 16.979454] [<0021502d>] ? vsnprintf+0xbd/0x420 [ 16.995672] [<00065500>] ? rsbac_list_register+0x50/0x60 [ 17.015863] [<0003ea00>] ? debug_adf_default_setup+0x10/0x10 [ 17.034819] [<0003f165>] ? rsbac_init_debug+0x365/0x8f0 [ 17.053388] [<0003ea00>] ? debug_adf_default_setup+0x10/0x10 [ 17.073106] [<00050825>] ? rsbac_init+0x395/0x1dd0 [ 17.089487] [<00004003>] ? math_error+0xe3/0x2c0 [ 17.113861] [<002141d1>] ? format_decode+0x321/0x390 [ 17.131050] [<0021502d>] ? vsnprintf+0xbd/0x420 [ 17.147358] [<000a9812>] ? __wake_up+0x42/0x60 [ 17.162557] [<0003ed88>] ? rsbac_printk+0x198/0x210 [ 17.179746] [<0003ed88>] ? rsbac_printk+0x198/0x210 [ 17.197012] [<00008001>] ? arch_get_unmapped_area_topdown+0x101/0x220 [ 17.219124] [<000525b7>] ? rsbac_mount+0x357/0x790 [ 17.236300] [<0015d1db>] ? alloc_vfsmnt+0xab/0x130 [ 17.252732] [<0015b211>] ? __get_fs_type+0x21/0x60 [ 17.269828] [<00008001>] ? arch_get_unmapped_area_topdown+0x101/0x220 [ 17.291864] [<0015f888>] ? vfs_kern_mount+0x68/0xb0 [ 17.309008] [<00008001>] ? arch_get_unmapped_area_topdown+0x101/0x220 [ 17.331338] [<0015f92f>] ? do_kern_mount+0x3f/0xe0 [ 17.348448] [<0015fb97>] ? do_mount+0x1c7/0x2c0 [ 17.382950] [<00008001>] ? arch_get_unmapped_area_topdown+0x101/0x220 [ 17.406003] [<0015fd02>] ? sys_mount+0x72/0xb0 [ 17.421929] [<00008001>] ? arch_get_unmapped_area_topdown+0x101/0x220 [ 17.444075] [<003515c1>] ? syscall_call+0x7/0xb [ 17.459275] [<00008001>] ? arch_get_unmapped_area_topdown+0x101/0x220 [ 17.481655] [<00024b00>] ? spurious_fault+0x120/0x120 [ 17.499394] [<003515e7>] ? restore_all_pax+0xc/0xc [ 17.516465] [<00010246>] ? amd_get_event_constraints+0xb6/0x120 [ 17.537225] [<00010246>] ? amd_get_event_constraints+0xb6/0x120 [ 17.557481] ---[ end trace 384eb6d8c66545f4 ]--- mount: permission denied (are you root?) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /sys on /root/sys failed: No such file or directory mount: mounting /proc on /root/proc failed: No such file or directory Target filesystem doesn't have requested /sbin/init. No init found. Try passing init= bootarg. -------------- n?chster Teil -------------- Unlocking the disk /dev/disk/by-uuid/afd88748-2faa-46fc-bd59-250e55fbb75e (vda5_crypt) Enter passphrase: udevd-event[275]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DM_RULES_FLAG': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DISK_RULES_FLAG': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_UDEV_DISABLE_OTHER_RULES_FLAG': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_UDEV_LOW_PRIORITY_FLAG': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_UDEV_FLAG7': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG0': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG1': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG2': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG3': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG4': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG5': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG6': No such file or directory udevd-event[275]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG7': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DM_RULES_FLAG': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DISK_RULES_FLAG': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_UDEV_DISABLE_OTHER_RULES_FLAG': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_UDEV_LOW_PRIORITY_FLAG': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_UDEV_FLAG7': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG0': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG1': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG2': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG3': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG4': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG5': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG6': No such file or directory udevd-event[307]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG7': No such file or directory Reading all physical volumes. This may take a while... Found volume group "rsbac" using metadata type lvm2 udevd-event[317]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DM_RULES_FLAG': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DISK_RULES_FLAG': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_UDEV_DISABLE_OTHER_RULES_FLAG': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_UDEV_LOW_PRIORITY_FLAG': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_UDEV_FLAG7': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG0': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG1': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG2': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG3': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG4': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG5': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG6': No such file or directory udevd-event[317]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG7': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DM_RULES_FLAG': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_UDEV_DISABLE_DISK_RULES_FLAG': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_UDEV_DISABLE_OTHER_RULES_FLAG': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_UDEV_LOW_PRIORITY_FLAG': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_UDEV_FLAG7': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG0': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG1': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG2': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG3': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG4': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG5': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG6': No such file or directory udevd-event[324]: import_file_into_env: can't open 'DM_SUBSYSTEM_UDEV_FLAG7': No such file or directory From aleph at mandriva.org Fri Nov 18 11:52:27 2011 From: aleph at mandriva.org (Gergely =?UTF-8?Q?L=C3=B3nyai?=) Date: Fri, 18 Nov 2011 03:52:27 -0700 Subject: [rsbac] =?utf-8?q?=5BFWD=3A_Rebuild_failed_on_x86=5F64_for_=40731?= =?utf-8?q?573=3Akernel-rsbac-3=2E0=2E8-1mdv2011=2E0=2Esrc=2Erpm=5D?= Message-ID: <20111118035227.9b05b4e5e48d18b6dc565714b379f9f0.033da60116.wbe@email07.europe.secureserver.net> Hi, I can't understand this error => I can't resolve this. The configs: attached. Source: from git://rsbac.org/linux-3.0 Please help me: Aleph > -------- Original Message -------- > Subject: Rebuild failed on x86_64 for > @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm > From: Ulri the scheduler bot > Date: Fri, November 18, 2011 11:11 am > To: Lonyai Gergely > > > Build of the following packages failed: > > - @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm > > Failure details available in http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log > Reason: > @731573:kernel-rsbac-3.0.8-1.src.rpm: build_failure > > Log files generated: > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/install_deps-1.0.20111118094316.log > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/rpm_qa.0.20111118094316.log > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/build.0.20111118094316.log --------- k?vetkez? r?sz --------- An embedded and charset-unspecified text was scrubbed... Name: i386.config URL: --------- k?vetkez? r?sz --------- An embedded and charset-unspecified text was scrubbed... Name: x86_64.config URL: From jens at kasten-edv.de Fri Nov 18 16:10:53 2011 From: jens at kasten-edv.de (Jens Kasten) Date: Fri, 18 Nov 2011 16:10:53 +0100 Subject: [rsbac] [FWD: Rebuild failed on x86_64 for @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm] In-Reply-To: <20111118035227.9b05b4e5e48d18b6dc565714b379f9f0.033da60116.wbe@email07.europe.secureserver.net> References: <20111118035227.9b05b4e5e48d18b6dc565714b379f9f0.033da60116.wbe@email07.europe.secureserver.net> Message-ID: <1321629053.12732.181.camel@malo.jaschtschik.local> Hi Aleph, I do use the same git source. When have you update your git repo last time? I did compile your i386 config in my git repo and got no errors. Gr??e Jens Am Freitag, den 18.11.2011, 03:52 -0700 schrieb Gergely L?nyai: > Hi, > > I can't understand this error => I can't resolve this. > > The configs: attached. > Source: from git://rsbac.org/linux-3.0 > > Please help me: > Aleph > > > -------- Original Message -------- > > Subject: Rebuild failed on x86_64 for > > @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm > > From: Ulri the scheduler bot > > Date: Fri, November 18, 2011 11:11 am > > To: Lonyai Gergely > > > > > > Build of the following packages failed: > > > > - @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm > > > > Failure details available in http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log > > Reason: > > @731573:kernel-rsbac-3.0.8-1.src.rpm: build_failure > > > > Log files generated: > > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/install_deps-1.0.20111118094316.log > > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/rpm_qa.0.20111118094316.log > > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/build.0.20111118094316.log > _______________________________________________ > rsbac mailing list > rsbac at rsbac.org > http://www.rsbac.org/mailman/listinfo/rsbac From gergely at lonyai.com Fri Nov 18 16:38:43 2011 From: gergely at lonyai.com (Gergely =?UTF-8?Q?L=C3=B3nyai?=) Date: Fri, 18 Nov 2011 08:38:43 -0700 Subject: [rsbac] =?utf-8?q?=5BFWD=3A_Rebuild_failed_on_x86=5F64_for_=40731?= =?utf-8?q?573=3Akernel-rsbac-3=2E0=2E8-1mdv2011=2E0=2Esrc=2Erpm=5D?= Message-ID: <20111118083843.9b05b4e5e48d18b6dc565714b379f9f0.efac21b919.wbe@email07.europe.secureserver.net> Hi, Sorry, I forgot the RSBAC configs. This is applied during the rpm build. Attached anew config. Aleph > -------- Original Message -------- > Subject: Re: [rsbac] [FWD: Rebuild failed on x86_64 for > @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm] > From: Jens Kasten > Date: Fri, November 18, 2011 4:10 pm > To: RSBAC Discussion and Announcements > > > Hi Aleph, > > I do use the same git source. > When have you update your git repo last time? > > I did compile your i386 config in my git repo and got no errors. > > Gr??e > Jens > > > Am Freitag, den 18.11.2011, 03:52 -0700 schrieb Gergely L?nyai: > > Hi, > > > > I can't understand this error => I can't resolve this. > > > > The configs: attached. > > Source: from git://rsbac.org/linux-3.0 > > > > Please help me: > > Aleph > > > > > -------- Original Message -------- > > > Subject: Rebuild failed on x86_64 for > > > @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm > > > From: Ulri the scheduler bot > > > Date: Fri, November 18, 2011 11:11 am > > > To: Lonyai Gergely > > > > > > > > > Build of the following packages failed: > > > > > > - @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm > > > > > > Failure details available in http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log > > > Reason: > > > @731573:kernel-rsbac-3.0.8-1.src.rpm: build_failure > > > > > > Log files generated: > > > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/install_deps-1.0.20111118094316.log > > > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/rpm_qa.0.20111118094316.log > > > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111118094059.aleph.kenobi.4470/log/kernel-rsbac-3.0.8-1/build.0.20111118094316.log > > _______________________________________________ > > rsbac mailing list > > rsbac at rsbac.org > > http://www.rsbac.org/mailman/listinfo/rsbac > > > > > _______________________________________________ > rsbac mailing list > rsbac at rsbac.org > http://www.rsbac.org/mailman/listinfo/rsbac -------------- next part -------------- A non-text attachment was scrubbed... Name: config_with_rsbac.gz Type: application/x-gzip Size: 34430 bytes Desc: not available URL: From kang at insecure.ws Sun Nov 20 15:07:34 2011 From: kang at insecure.ws (kang) Date: Sun, 20 Nov 2011 15:07:34 +0100 Subject: [rsbac] [FWD: Rebuild failed on x86_64 for @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm] In-Reply-To: <20111118083843.9b05b4e5e48d18b6dc565714b379f9f0.efac21b919.wbe@email07.europe.secureserver.net> References: <20111118083843.9b05b4e5e48d18b6dc565714b379f9f0.efac21b919.wbe@email07.europe.secureserver.net> Message-ID: <4EC909A6.2020005@insecure.ws> It seems to be an error in the ifdefs with CONFIG_RSBAC_DEBUG This is at: http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-3.0.y.git;a=blob;f=net/unix/af_unix.c;h=8476f0129a119ea7977d5da451d40030fba78826;hb=HEAD#l1513 The source fix is something like (in net/unix/af_unix.c, lines 1512+) 1512 #ifdef CONFIG_RSBAC_NET 1513 #ifdef CONFIG_RSBAC_DEBUG 1513 if ( rsbac_debug_aef_net ... Alternatively you can build with CONFIG_RSBAC_DEBUG set in the config until a fix is committed kang On 11/18/2011 4:38 PM, Gergely L?nyai wrote: > Hi, > > Sorry, I forgot the RSBAC configs. This is applied during the rpm build. > Attached anew config. > > Aleph > g/mailman/listinfo/rsbac From gergely at lonyai.com Sun Nov 20 22:56:50 2011 From: gergely at lonyai.com (Gergely =?UTF-8?Q?L=C3=B3nyai?=) Date: Sun, 20 Nov 2011 14:56:50 -0700 Subject: [rsbac] =?utf-8?q?=5BFWD=3A_Rebuild_failed_on_x86=5F64_for_=40731?= =?utf-8?q?573=3Akernel-rsbac-3=2E0=2E8-1mdv2011=2E0=2Esrc=2Erpm=5D?= Message-ID: <20111120145650.9b05b4e5e48d18b6dc565714b379f9f0.04c0f15dfa.wbe@email07.europe.secureserver.net> Hi, This kernel version is in a released distribution. I can't set on the debug option this kernel. I need to wait the patch this error. Aleph > -------- Original Message -------- > Subject: Re: [rsbac] [FWD: Rebuild failed on x86_64 for > @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm] > From: kang > Date: Sun, November 20, 2011 3:07 pm > To: RSBAC Discussion and Announcements > Cc: ao at rsbac.org > > > It seems to be an error in the ifdefs with CONFIG_RSBAC_DEBUG > > This is at: > http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-3.0.y.git;a=blob;f=net/unix/af_unix.c;h=8476f0129a119ea7977d5da451d40030fba78826;hb=HEAD#l1513 > > The source fix is something like (in net/unix/af_unix.c, lines 1512+) > > 1512 #ifdef CONFIG_RSBAC_NET > 1513 #ifdef CONFIG_RSBAC_DEBUG > 1513 if ( rsbac_debug_aef_net > ... > > Alternatively you can build with CONFIG_RSBAC_DEBUG set in the config > until a fix is committed > > kang > > On 11/18/2011 4:38 PM, Gergely L?nyai wrote: > > Hi, > > > > Sorry, I forgot the RSBAC configs. This is applied during the rpm build. > > Attached anew config. > > > > Aleph > > g/mailman/listinfo/rsbac > > _______________________________________________ > rsbac mailing list > rsbac at rsbac.org > http://www.rsbac.org/mailman/listinfo/rsbac From ao at rsbac.org Mon Nov 21 10:02:59 2011 From: ao at rsbac.org (Amon Ott) Date: Mon, 21 Nov 2011 10:02:59 +0100 Subject: [rsbac] [FWD: Rebuild failed on x86_64 for @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm] In-Reply-To: <20111120145650.9b05b4e5e48d18b6dc565714b379f9f0.04c0f15dfa.wbe@email07.europe.secureserver.net> References: <20111120145650.9b05b4e5e48d18b6dc565714b379f9f0.04c0f15dfa.wbe@email07.europe.secureserver.net> Message-ID: <201111211002.59946.ao@rsbac.org> On Sunday 20 November 2011 wrote Gergely L?nyai: > This kernel version is in a released distribution. I can't set on the > debug option this kernel. I need to wait the patch this error. I have just pushed the compile fix and 3.0.9. You can just apply dfe84d5d0842e30dd28f976ec2ce62be6e7bdc3b for the fix or go to 3.0.9. Additionally, we also have 3.1.1 in a new repo available at rsbac.org. RSBAC_DEBUG also allows to debug RSBAC settings, not only the RSBAC itself. So I recommend turning it on even for production systems - we also have it on everywhere. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 From gergely at lonyai.com Mon Nov 21 11:01:49 2011 From: gergely at lonyai.com (Gergely =?UTF-8?Q?L=C3=B3nyai?=) Date: Mon, 21 Nov 2011 03:01:49 -0700 Subject: [rsbac] =?utf-8?q?=5BFWD=3A_Rebuild_failed_on_x86=5F64_for_=40731?= =?utf-8?q?573=3Akernel-rsbac-3=2E0=2E8-1mdv2011=2E0=2Esrc=2Erpm=5D?= Message-ID: <20111121030149.9b05b4e5e48d18b6dc565714b379f9f0.1f2ee396ac.wbe@email07.europe.secureserver.net> Hi, Ok. I will turn On the debug in config. But: Build failure reason(s): EE: gcc: unknown error: redeclaration of 'rsbac_target_id' with no linkage EE: gcc: unknown error: expected identifier or '(' before '<<' token http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/20111121095232.aleph.kenobi.13963/log/kernel-rsbac-3.0.9-1/build.0.20111121095311.log > -------- Original Message -------- > Subject: Re: [rsbac] [FWD: Rebuild failed on x86_64 for > @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm] > From: Amon Ott > Date: Mon, November 21, 2011 10:02 am > To: RSBAC Discussion and Announcements > > > On Sunday 20 November 2011 wrote Gergely L?nyai: > > This kernel version is in a released distribution. I can't set on the > > debug option this kernel. I need to wait the patch this error. > > I have just pushed the compile fix and 3.0.9. You can just apply > dfe84d5d0842e30dd28f976ec2ce62be6e7bdc3b for the fix or go to 3.0.9. > Additionally, we also have 3.1.1 in a new repo available at rsbac.org. > > RSBAC_DEBUG also allows to debug RSBAC settings, not only the RSBAC itself. So > I recommend turning it on even for production systems - we also have it on > everywhere. > > Amon. > -- > http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 > _______________________________________________ > rsbac mailing list > rsbac at rsbac.org > http://www.rsbac.org/mailman/listinfo/rsbac From ao at rsbac.org Mon Nov 21 11:38:30 2011 From: ao at rsbac.org (Amon Ott) Date: Mon, 21 Nov 2011 11:38:30 +0100 Subject: [rsbac] [FWD: Rebuild failed on x86_64 for @731573:kernel-rsbac-3.0.8-1mdv2011.0.src.rpm] In-Reply-To: <20111121030149.9b05b4e5e48d18b6dc565714b379f9f0.1f2ee396ac.wbe@email07.europe.secureserver.net> References: <20111121030149.9b05b4e5e48d18b6dc565714b379f9f0.1f2ee396ac.wbe@email07.europe.secureserver.net> Message-ID: <201111211138.30460.ao@rsbac.org> On Monday 21 November 2011 wrote Gergely L?nyai: > Hi, > > Ok. I will turn On the debug in config. > > But: > Build failure reason(s): > EE: gcc: unknown error: redeclaration of 'rsbac_target_id' with no > linkage > EE: gcc: unknown error: expected identifier or '(' before '<<' token > http://kenobi.mandriva.com/queue/failure/2011/contrib/updates/2011112109523 >2.aleph.kenobi.13963/log/kernel-rsbac-3.0.9-1/build.0.20111121095311.log The errors look like merging problems. Please look into your code at the error places and compare to the code at git.rsbac.org. Specially the "<<" errors look like merge markings, which have not been resolved. The enums are correct this way, enum rsbac_rc_special_rights_t is an extension of enum rsbac_adf_request_t. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 From ao at rsbac.org Wed Nov 30 09:42:23 2011 From: ao at rsbac.org (Amon Ott) Date: Wed, 30 Nov 2011 09:42:23 +0100 Subject: [rsbac] Security bugfix for RSBAC for kernels 2.6.35 and later Message-ID: <201111300942.24974.ao@rsbac.org> Hello everyone, unfortunately, there is a severe bug in the code that determines the RSBAC request type in sys_open() calls. As a result from this bug, open access will be decided upon by RSBAC with wrong request type, a read open can happen unnoticed. A read() access after opening is intercepted as intended, because only the open interception is wrong. Affected are all RSBAC git repos for kernels starting from 2.6.35 and the official release 1.4.5 for 2.6.35. RSBAC for kernel 2.6.32 is not affected. Please update your kernel sources from git or apply the attached patch for 2.6.35.y and rebuild to get the bug fixed. I will try to get a new release out for kernel 3.1.4 or later as soon as possible. After fixing, your system might need RSBAC rights adjustments, because the set of accesses changes. Background: Between 2.6.32 and 2.6.35, the meaning of the flags parameter for sys_open() helper functions changed from some translated internal value to an exact copy of the sys_open() flags parameter. When porting RSBAC code from 2.6.32, we did not notice that change. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 -------------- next part -------------- A non-text attachment was scrubbed... Name: openmode.diff Type: text/x-diff Size: 1456 bytes Desc: not available URL: From tazok.id0 at gmail.com Wed Nov 30 15:46:13 2011 From: tazok.id0 at gmail.com (=?ISO-8859-1?Q?Javier_Juan_Mart=EDnez_Cabez=F3n?=) Date: Wed, 30 Nov 2011 15:46:13 +0100 Subject: [rsbac] Security bugfix for RSBAC for kernels 2.6.35 and later In-Reply-To: <201111300942.24974.ao@rsbac.org> References: <201111300942.24974.ao@rsbac.org> Message-ID: Amon, in which case would this be a security problem? AFAIK, READ_OPEN calls are uneeded because they always require de READ one to access de contents of the file. So I have never found a case in which READ_OPEN should be granted and READ not. To me READ_OPEN is only userful to restrict scripts interpretation and nothing more. 2011/11/30 Amon Ott > Hello everyone, > > unfortunately, there is a severe bug in the code that determines the RSBAC > request type in sys_open() calls. As a result from this bug, open access > will > be decided upon by RSBAC with wrong request type, a read open can happen > unnoticed. A read() access after opening is intercepted as intended, > because > only the open interception is wrong. > > Affected are all RSBAC git repos for kernels starting from 2.6.35 and the > official release 1.4.5 for 2.6.35. RSBAC for kernel 2.6.32 is not affected. > > Please update your kernel sources from git or apply the attached patch for > 2.6.35.y and rebuild to get the bug fixed. I will try to get a new release > out for kernel 3.1.4 or later as soon as possible. After fixing, your > system > might need RSBAC rights adjustments, because the set of accesses changes. > > Background: Between 2.6.32 and 2.6.35, the meaning of the flags parameter > for > sys_open() helper functions changed from some translated internal value to > an > exact copy of the sys_open() flags parameter. When porting RSBAC code from > 2.6.32, we did not notice that change. > > Amon. > -- > http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 > > _______________________________________________ > rsbac mailing list > rsbac at rsbac.org > http://www.rsbac.org/mailman/listinfo/rsbac > From ao at rsbac.org Wed Nov 30 16:33:51 2011 From: ao at rsbac.org (Amon Ott) Date: Wed, 30 Nov 2011 16:33:51 +0100 Subject: [rsbac] Security bugfix for RSBAC for kernels 2.6.35 and later In-Reply-To: References: <201111300942.24974.ao@rsbac.org> Message-ID: <201111301633.52283.ao@rsbac.org> On Wednesday 30 November 2011 wrote Javier Juan Mart?nez Cabez?n: > Amon, in which case would this be a security problem? > > AFAIK, READ_OPEN calls are uneeded because they always require de READ one > to access de contents of the file. > > So I have never found a case in which READ_OPEN should be granted and READ > not. > > To me READ_OPEN is only userful to restrict scripts interpretation and > nothing more. READ is required to read the content of a dir, so it is quite often allowed on whole trees or RC types. If READ_OPEN is not denied, then you can read content of files, although you should only have access to the dir listing. Additionally, intercepting READ and WRITE on files is optional, you can turn it off in RSBAC kernel config. The reason is that you need to open it first... Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 From ao at rsbac.org Wed Nov 30 16:54:30 2011 From: ao at rsbac.org (Amon Ott) Date: Wed, 30 Nov 2011 16:54:30 +0100 Subject: [rsbac] rsbac.org moving Message-ID: <201111301654.31486.ao@rsbac.org> Hello everyone, the rsbac.org server is moving to new hardware with a new IP. There will be some outage tomorrow while final syncing of data and configuration update happen. By the end of tomorrow I expect everything to be up and running fine. Please expect some temporary problems. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 From tazok.id0 at gmail.com Wed Nov 30 17:04:05 2011 From: tazok.id0 at gmail.com (=?ISO-8859-1?Q?Javier_Juan_Mart=EDnez_Cabez=F3n?=) Date: Wed, 30 Nov 2011 17:04:05 +0100 Subject: [rsbac] Security bugfix for RSBAC for kernels 2.6.35 and later In-Reply-To: <201111301633.52283.ao@rsbac.org> References: <201111300942.24974.ao@rsbac.org> <201111301633.52283.ao@rsbac.org> Message-ID: I didn't get realized about this scenary. So if the type of files are inherited from parent dir, and READ is granted to parent dir then this role could read contents of files with independency of READ_OPEN is granted or not to the file. In the second scenary (with READ WRITE interception disabled in kernel) if I'm not wrong if READ is granted to parent dir then every access would be answered DON'T CARE since is not checked, and because of this always granted with or without READ_OPEN priv. It's clear now, thanks Amon 2011/11/30 Amon Ott > On Wednesday 30 November 2011 wrote Javier Juan Mart?nez Cabez?n: > > Amon, in which case would this be a security problem? > > > > AFAIK, READ_OPEN calls are uneeded because they always require de READ > one > > to access de contents of the file. > > > > So I have never found a case in which READ_OPEN should be granted and > READ > > not. > > > > To me READ_OPEN is only userful to restrict scripts interpretation and > > nothing more. > > READ is required to read the content of a dir, so it is quite often > allowed on > whole trees or RC types. If READ_OPEN is not denied, then you can read > content of files, although you should only have access to the dir listing. > > Additionally, intercepting READ and WRITE on files is optional, you can > turn > it off in RSBAC kernel config. The reason is that you need to open it > first... > > Amon. > -- > http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 > _______________________________________________ > rsbac mailing list > rsbac at rsbac.org > http://www.rsbac.org/mailman/listinfo/rsbac >