Hi,
Just got the system up with the latest changes.
kudzu-1.1.87-1, MAKEDEV-3.12-1, udev-030-22, & hal-0.2.97.cvs20040901-1.
First, I get this message:
Sep 9 08:44:43 buildhost kernel: PCI: Probing PCI hardware (bus 00) Sep 9 08:44:43 buildhost kernel: get_random_bytes called before random driver initialization
This doesn't sound good.
Then I got a series of messages like: "/sbin/restorecon get context on /dev failed: Operation not supported" "/usr/sbin/setfiles unable to obtain attr for /dev"
These did not get into syslog. Problems from restorecon & setfiles like this should be logged.
Then kudzu detected my usb hub twice.
And finally:
Sep 9 08:44:53 buildhost fstab-sync[2607]: removed all generated mount points Sep 9 08:44:53 buildhost fstab-sync[2649]: added mount point /media/idedisk for /dev/hda5 Sep 9 08:44:54 buildhost fstab-sync[2655]: added mount point /media/idedisk1 for /dev/hda1 Sep 9 08:44:54 buildhost fstab-sync[2686]: added mount point /media/scsidisk for /dev/sda2 Sep 9 08:44:54 buildhost fstab-sync[2689]: added mount point /media/scsidisk1 for /dev/sda1
I hand edit my /etc/fstab to only have these disks: /dev/sda3, /dev/sda5. I really do not want anything else accessible to the system...its a security violation in my view. The sad part is that it did not recognize the cdrom which is /dev/hdc.
-Steve Grubb
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
[...]
Then I got a series of messages like: "/sbin/restorecon get context on /dev failed: Operation not supported" "/usr/sbin/setfiles unable to obtain attr for /dev"
These did not get into syslog. Problems from restorecon & setfiles like this should be logged.
Have you rebuilt your initd with a recent version of mkinitrd? Mkinitrd and udev now use tmpfs instead of ramfs to host /dev. Tmpfs supports SELinux EA's (with the patch Red Hat applies). Ramfs does not.
[...]
-- Mike
Have you rebuilt your initd with a recent version of mkinitrd?
Yes, I use mkinitrd-4.1.9-1. I also still have 2 /proc's and 2 /dev's. So who knows which /dev its complaining about.
/proc /proc proc rw,nodiratime 0 0 none /dev tmpfs rw 0 0 /dev/root / ext3 rw 0 0 none /dev tmpfs rw 0 0 none /selinux selinuxfs rw 0 0 /proc /proc proc rw,nodiratime 0 0
-Steve Grubb
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
On Thu, 9 Sep 2004 06:05:17 -0700 (PDT), Steve G linux_4ever@yahoo.com wrote:
I hand edit my /etc/fstab to only have these disks: /dev/sda3, /dev/sda5. I really do not want anything else accessible to the system...its a security violation in my view. The sad part is that it did not recognize the cdrom which is /dev/hdc.
Sounds to me like you need to either complete disable hal or invest some time into learning how to configure hal for your local system policy to show only devices of your choosing.
-jef
On Thu, 2004-09-09 at 06:05 -0700, Steve G wrote:
Sep 9 08:44:53 buildhost fstab-sync[2607]: removed all generated mount points Sep 9 08:44:53 buildhost fstab-sync[2649]: added mount point /media/idedisk for /dev/hda5 Sep 9 08:44:54 buildhost fstab-sync[2655]: added mount point /media/idedisk1 for /dev/hda1 Sep 9 08:44:54 buildhost fstab-sync[2686]: added mount point /media/scsidisk for /dev/sda2 Sep 9 08:44:54 buildhost fstab-sync[2689]: added mount point /media/scsidisk1 for /dev/sda1
Are there valid mountable filesystems on these partitions?
I hand edit my /etc/fstab to only have these disks: /dev/sda3, /dev/sda5. I really do not want anything else accessible to the system...its a security violation in my view.
I'm not sure I agree: if one cares about security one is using filesystems with uid/gid attributes anyway. That said, however, it might be useful to have a configuration file fstab-sync to explicitly specify don't add this or that drive. And in the longterm finetune the mount point names, e.g. using labels or whatnot.
You could also just remove the kudzu,user option from the fstab file for the entries you are concerned about. That way they wont get added the next time you start the haldaemon service and no unprivileged user is able to mount them.
The sad part is that it did not recognize the cdrom which is /dev/hdc.
This should work. What does 'udevinfo -r -q name -p /block/hdc' say?
I've seen on some occasions that udevstart doesn't run; at least the udev database isn't populated with sufficient information to do the udevinfo. Does running 'service haldaemon stop; udevstart; service haldaemon start' solve your problem? Does ude
Otherwise you need to file a bug against hal to we can fix it.
Thanks, David
On Thu, 09 Sep 2004 20:21:00 +0200, David Zeuthen david@fubar.dk wrote:
I'm not sure I agree: if one cares about security one is using filesystems with uid/gid attributes anyway. That said, however, it might be useful to have a configuration file fstab-sync to explicitly specify don't add this or that drive. And in the longterm finetune the mount point names, e.g. using labels or whatnot.
I think if someone wants to approach this from a locked down system point of view, you'd want to have a a policy of no devices allowed by default with specific devices allowed via administrative control. As compared to a policy of everything by default with a list of devices disallowed. Though of course both approaches will have their uses.
I'm still poking at figuring out how to break hal in spectacular ways... but are the files in /usr/share/hal/fdi useful for creating locally defined policy of this sort?
-jef
On Thu, Sep 09, 2004 at 03:07:24PM -0400, Jeff Spaleta wrote:
I'm still poking at figuring out how to break hal in spectacular ways... but are the files in /usr/share/hal/fdi useful for creating locally defined policy of this sort?
I would hope not because /usr can be shared. Local policy belongs in /etc 8)
On Thu, 2004-09-09 at 15:07 -0400, Jeff Spaleta wrote:
On Thu, 09 Sep 2004 20:21:00 +0200, David Zeuthen david@fubar.dk wrote:
I'm not sure I agree: if one cares about security one is using filesystems with uid/gid attributes anyway. That said, however, it might be useful to have a configuration file fstab-sync to explicitly specify don't add this or that drive. And in the longterm finetune the mount point names, e.g. using labels or whatnot.
I think if someone wants to approach this from a locked down system point of view, you'd want to have a a policy of no devices allowed by default with specific devices allowed via administrative control. As compared to a policy of everything by default with a list of devices disallowed. Though of course both approaches will have their uses.
Yeah, I'm thinking /etc/fstab-sync.conf would do this - still have to write the code but it shouldn't be too hard. I'm not sure what the default policy should be though - most people are happy about not having to go to the commandline to get access to their partitions and some people have more or less valid security concerns. My take is that the latter group is more capable of going and editing /etc/fstab-sync.conf that the former. But that is just my personal opinion.
I'm still poking at figuring out how to break hal in spectacular ways... but are the files in /usr/share/hal/fdi useful for creating locally defined policy of this sort?
Those files, hal device information files, or .fdi files, are meant to contain *facts* about certain devices, e.g. this device that looks like a mass storage device to the kernel is in fact really a mp3 player/ camera/whatever. So, yes Alan, they are really suitable to be shared between archs and used site-wide etc.
David
I'm not sure what the default policy should be though - most people are happy about not having to go to the commandline to get access to their partitions and some people have more or less valid security concerns.
OK, I've had some time to think this over. Traditionally, the default is on the open - all inclusive side of things unless there is the possibility of damage. e.g., tcp_wrapper defaults to open, iptable defaults to open. You must intervene to secure the system.
As long as the drives are only detected and mount points made, it don't have a problem. If the drives are *mounted*, I have a real problem. By mounting the drive, you may suddenly cause a drive to get fsck'ed by a newer program that oopses older kernels, or relabeled by SE Linux which will oops older kernels.
No mounting!
Even thought I have hand edited my fstab and hal made mount points, it appears not to have mounted the drives.
Based on a suggestion from Jeff yesterday, I went and tuned my /etc/hal/hald.conf file for false, false, false. On next boot, the mount points disappeared. Then I re-installed hal. My config file was renamed hald.cond.rpmorig. :( There needs to be a %config(noreplace) for hald.conf in the spec file.
Also, on first boot, hal ignores my wishes and puts the mount points there. I haven't tried a reboot yet to see if on second boot they go away. Not sure yet if this is a regression from yesterdays updates or just a first boot behavior.
Next question, is there supposed to be a /media/cdrom mount point? or is it still /dev/cdrom? Or both?
Those files, hal device information files, or .fdi files, are meant to contain *facts* about certain devices, e.g. this device that looks like a mass storage device to the kernel is in fact really a mp3 player/ camera/whatever.
I am wondering about people that have /usr as nfs? I think that's why things that have a bearing on config keep a copy in /etc. For example, timezone data. The master copy is under /usr somewhere, but its copied to /etc.
-Steve Grubb
_______________________________ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool
On Fri, 2004-09-10 at 05:40 -0700, Steve G wrote:
I'm not sure what the default policy should be though - most people are happy about not having to go to the commandline to get access to their partitions and some people have more or less valid security concerns.
OK, I've had some time to think this over. Traditionally, the default is on the open - all inclusive side of things unless there is the possibility of damage. e.g., tcp_wrapper defaults to open, iptable defaults to open. You must intervene to secure the system.
As long as the drives are only detected and mount points made, it don't have a problem. If the drives are *mounted*, I have a real problem. By mounting the drive, you may suddenly cause a drive to get fsck'ed by a newer program that oopses older kernels, or relabeled by SE Linux which will oops older kernels.
No mounting!
Even thought I have hand edited my fstab and hal made mount points, it appears not to have mounted the drives.
Sure, hal doesn't mount drives.
However, when you log in to GNOME then gnome-volume-manager, in the default configuration, mounts all the drives as the user who is logging in. And unmounts them at logout. I think this is sane given the options put in /etc/fstab. An example from my fstab
/dev/sda1 /media/compact_flash vfat noauto,user,exec,kudzu,noatime,sync 0 0
and it's mounted as
/dev/sda1 /media/compact_flash vfat rw,sync,noatime,nodiratime,nosuid,nodev,uid=500,gid=500,fmask=0022,dmask=0022 0 0
Note the nosuid,nodev options thanks to having user in the fstab line.
So, I hope we can agree this is pretty safe?
Based on a suggestion from Jeff yesterday, I went and tuned my /etc/hal/hald.conf file for false, false, false.
That is bad advice; I'm not sure how well turning off media detection works presently (I test it once in a while though) and I think g-v-m ignores the automount hint. When Nautilus and GNOME VFS is ready, this will be supported as well [1].
[1] : GNOME VFS presently relies on the fstab, but there is no fstab entry if there is no media in card and there wont be if media detection is disabled :-)
On next boot, the mount points disappeared. Then I re-installed hal. My config file was renamed hald.cond.rpmorig. :( There needs to be a %config(noreplace) for hald.conf in the spec file.
Sounds like a bug that is easy to fix. I'll do that, thanks for pointing it out.
Also, on first boot, hal ignores my wishes and puts the mount points there. I haven't tried a reboot yet to see if on second boot they go away. Not sure yet if this is a regression from yesterdays updates or just a first boot behavior.
Disabling media detection in /etc/hal/hald.conf only means we won't poll for media if we otherwise would do that. So of course hal initially detects your devices and create mount points.
Next question, is there supposed to be a /media/cdrom mount point? or is it still /dev/cdrom? Or both?
There is supposed to be a /media/cdrom mount point if you got a CD-ROM only drive; if it's a DVD-ROM it will be /media/dvdrom, if it's a CD- RW/DVD-RW it will be /media/cdrw_dvdrw and so on. It will probably reference the non-symlinked device e.g. /dev/hdc, /dev/hdd, /dev/sr0 or whatever.
With the latest udev, however, there will be compatibility symlinks /dev/cdrom, /dev/cdrom1, ... that points to the real device file e.g. /dev/hdc. hal doesn't really care about these symlinks.
David
However, when you log in to GNOME then gnome-volume-manager, in the default configuration, mounts all the drives as the user who is logging in. And unmounts them at logout. I think this is sane given the options put in /etc/fstab.
/dev/sda1 /media/compact_flash vfat rw,sync,noatime,nodiratime,nosuid,nodev,uid=500,gid=500,fmask=0022,dmask=0022 0
0
Note the nosuid,nodev options thanks to having user in the fstab line.
So, I hope we can agree this is pretty safe?
The damage comes from xattr. Suppose I have a machine that boots Mandrake, debian, and FC3. I use the /opt as a pass between the the various OS's. It is on its own partition. One of these days, the mount count triggers a fsck. I don't want it to write anything to the drive if it can mess it up. Again, the problem is xattrs and the older OS's not handling them.
<rant> Its too late now, but I think allowing xattrs into ext3 was a big mistake from a backwards compatibility stance. It should have been ext4. Sure, the bugs in ext3 would still be there waiting to bite you, but you won't face them every single day.</rant>
Can you detect a ext3 drive that doesn't have xattrs applied? If so, the work around is not to write anything related to xattrs to that drive.
I'm not sure how well turning off media detection works presently
Something changed after yesterday's updates. I set everything to false yesterday and there were no entries in /media and fstab. Today they are there.
(I test it once in a while though) and I think g-v-m ignores the automount hint. When Nautilus and GNOME VFS is ready, this will be supported as well [1].
Then the answer is not to make the drive available. There should probably be a configuration option that says do not update fstab with detected media and another for do not create mount points for detected media. This way, people that cannot afford to get a corrupted partition from xattrs being written to a partition that a NON-SE Linux OS must access can avoid damage.
There is supposed to be a /media/cdrom mount point if you got a CD-ROM drive;
OK, I don't see one. The following is from an earlier e-mail to the list that I didn't get a chance to answer:
This should work. What does 'udevinfo -r -q name -p /block/hdc' say?
/dev/hdc
Does running 'service haldaemon stop; udevstart; service haldaemon start' solve your problem?
No. [root@buildhost root]# ls /media/ idedisk idedisk1 scsidisk scsidisk1
[root@buildhost root]# service haldaemon stop Stopping HAL daemon: [FAILED] [root@buildhost root]# udevstart [root@buildhost root]# service haldaemon start Starting HAL daemon: [ OK ] /etc/init.d/haldaemon: line 31: /var/run/hald/pid: No such file or directory
Otherwise you need to file a bug against hal to we can fix it
Does the above look like a bug? If so I will file one.
Thanks, -Steve Grubb
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
Steve G wrote:
<rant> Its too late now, but I think allowing xattrs into ext3 was a big mistake from a backwards compatibility stance. It should have been ext4. Sure, the bugs in ext3 would still be there waiting to bite you, but you won't face them every single day.</rant>
Reading the kernel list.. I think that Linus has a similar opinion :).
Hmm... will ext3 suddeny change name to ext4? That would be... interesting.
fre, 10.09.2004 kl. 20.38 skrev Stephen J Smoogen:
Steve G wrote:
<rant> Its too late now, but I think allowing xattrs into ext3 was a big mistake from a backwards compatibility stance. It should have been ext4. Sure, the bugs in ext3 would still be there waiting to bite you, but you won't face them every single day.</rant>
Reading the kernel list.. I think that Linus has a similar opinion :).
-- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen@lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 |
On Fri, 2004-09-10 at 10:27 -0700, Steve G wrote:
The damage comes from xattr. Suppose I have a machine that boots Mandrake, debian, and FC3. I use the /opt as a pass between the the various OS's. It is on its own partition. One of these days, the mount count triggers a fsck. I don't want it to write anything to the drive if it can mess it up. Again, the problem is xattrs and the older OS's not handling them.
<rant> Its too late now, but I think allowing xattrs into ext3 was a big mistake from a backwards compatibility stance. It should have been ext4. Sure, the bugs in ext3 would still be there waiting to bite you, but you won't face them every single day.</rant>
Can you detect a ext3 drive that doesn't have xattrs applied? If so, the work around is not to write anything related to xattrs to that drive.
It sounds to me like this should be fixed in the kernel.
I'm not sure how well turning off media detection works presently
Something changed after yesterday's updates. I set everything to false yesterday and there were no entries in /media and fstab. Today they are there.
(I test it once in a while though) and I think g-v-m ignores the automount hint. When Nautilus and GNOME VFS is ready, this will be supported as well [1].
Then the answer is not to make the drive available. There should probably be a configuration option that says do not update fstab with detected media and another for do not create mount points for detected media.
Maintaining mountpoints == maintaining /etc/fstab. There will be a configuration for fstab-sync to specify whether a drive or media should be ignored. So you'll be able to say something like
block.device="/dev/hda7", ignore storage.serial="CLP225F2G3UR4A", ignore block.device="/dev/hda2", mount_point="/mnt/my_own_mount_point" volume.label="CANON_DC", mount_point="/mnt/my_camera", options="noauto,user,exec,noatime,sync"
or something - need to work out the exact format but it will be simple and probably like the udev rules.
This way, people that cannot afford to get a corrupted partition from xattrs being written to a partition that a NON-SE Linux OS must access can avoid damage.
I'm not sure how to best work around the xattr issue and I'm wary at adding special casing code at the hal level for this - I'm more of the opinion that this should be solved at the kernel level and I'm curious at what other people think.
There is supposed to be a /media/cdrom mount point if you got a CD-ROM drive;
OK, I don't see one. The following is from an earlier e-mail to the list that I didn't get a chance to answer:
Right.
This should work. What does 'udevinfo -r -q name -p /block/hdc' say?
/dev/hdc
Looks good.
Does running 'service haldaemon stop; udevstart; service haldaemon start' solve your problem?
No. [root@buildhost root]# ls /media/ idedisk idedisk1 scsidisk scsidisk1
[root@buildhost root]# service haldaemon stop Stopping HAL daemon: [FAILED] [root@buildhost root]# udevstart [root@buildhost root]# service haldaemon start Starting HAL daemon: [ OK ] /etc/init.d/haldaemon: line 31: /var/run/hald/pid: No such file or directory
Otherwise you need to file a bug against hal to we can fix it
Does the above look like a bug? If so I will file one.
It indeed looks like hald crashed - haven't seen that in some time though :-). Yes, please submit a bug report; I wrote down some information about what to capture here
http://freedesktop.org/Software/HalTraces
Many thanks, David
On Sat, 11 Sep 2004 09:33:58 +0200, David Zeuthen david@fubar.dk wrote:
Maintaining mountpoints == maintaining /etc/fstab. There will be a configuration for fstab-sync to specify whether a drive or media should be ignored. So you'll be able to say something like
block.device="/dev/hda7", ignore storage.serial="CLP225F2G3UR4A", ignore block.device="/dev/hda2", mount_point="/mnt/my_own_mount_point" volume.label="CANON_DC", mount_point="/mnt/my_camera", options="noauto,user,exec,noatime,sync"
or something - need to work out the exact format but it will be simple and probably like the udev rules.
sweeeeeeeeet being able to pre-define what the mountpoints will be called would be nice for specific devices. Being able to set an ignore policy for all devices or for ranges of devices would be good too. Should I open up an RFE in bugzilla with more specific ideas fro fstab-sync configuratrion?
-jef
Can you detect a ext3 drive that doesn't have xattrs applied? If so, the work around is not to write anything related to xattrs to that drive.
It sounds to me like this should be fixed in the kernel.
Agreed. A solution in the kernel would be ideal. However, I cannot assume that will ever happen. I am looking for a work around that prevents the problem from occurring in the first place. I think it can be done by simply not having enough info available for automounting programs to "connect the dots".
I'm not sure how well turning off media detection works presently
Something changed after yesterday's updates. I set everything to false yesterday and there were no entries in /media and fstab. Today they are there.
I found this problem. My shell script didn't provide quotes to the xml attribute tags. parse error. This all works fine.
Maintaining mountpoints == maintaining /etc/fstab. There will be a configuration for fstab-sync to specify whether a drive or media should be ignored. So you'll be able to say something like
block.device="/dev/hda7", ignore storage.serial="CLP225F2G3UR4A", ignore block.device="/dev/hda2", mount_point="/mnt/my_own_mount_point" volume.label="CANON_DC", mount_point="/mnt/my_camera", options="noauto,user,exec,noatime,sync"
It would be nice if the syntax was awk or bash friendly. I plan to write a configuration tool for this in the ccs tools.
I'm not sure how to best work around the xattr issue and I'm wary at adding special casing code at the hal level for this - I'm more of the opinion that this should be solved at the kernel level and I'm curious at what other people think.
Maybe the above syntax will be enough for a work around. That's all I'm after for the short term. Where are these config files to be kept? /etc or /usr? If /usr, be sure to test on a computer that has /usr on a separate partition. I also wonder how well it works from a nash shell when something blows up during boot. :) With the xattr oops problem affecting me everyday, I'm sure I'll find out...
2 bugzilla reports were filed for hal.
-Steve Grubb
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Fri, 2004-09-10 at 05:40 -0700, Steve G wrote:
I'm not sure what the default policy should be though - most people are happy about not having to go to the commandline to get access to their partitions and some people have more or less valid security concerns.
OK, I've had some time to think this over. Traditionally, the default is on the open - all inclusive side of things unless there is the possibility of damage. e.g., tcp_wrapper defaults to open, iptable defaults to open. You must intervene to secure the system.
As long as the drives are only detected and mount points made, it don't have a problem. If the drives are *mounted*, I have a real problem. By mounting the drive, you may suddenly cause a drive to get fsck'ed by a newer program that oopses older kernels,
Has this actually happened?
or relabeled by SE Linux which will oops older kernels.
Yes; it's really a bug that the default relabeling procedure will try to relabel mount points. I've submitted a patch to fix this.
As long as the drives are only detected and mount points made, it don't have a problem. If the drives are *mounted*, I have a real problem. By mounting the drive, you may suddenly cause a drive to get fsck'ed by a newer program that oopses older kernels,
Has this actually happened?
Yes. I have a drive that is a pass between 2 OS's that's partitioned as ext3. When FC3 does anything to that drive & I reboot into another OS, it oopses. Sometimes on boot it drops me to a nash console where I basically reformat the partition to recover.
-Steve Grubb
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail