On 8:12:45 am 11/01/08 Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > On Saturday 01 November 2008 03:14:05 Dax Kelson wrote: > > On Sat, 2008-11-01 at 01:09 -0600, Dax Kelson wrote: > > > On Wed, 2008-10-29 at 15:02 -0400, Steve Grubb wrote: > > > > We tried to support this in F-10 by having a test run with > > > > ping. We figured that is a simple well defined app that could > > > > be used as a test subject. We opened bz 455713 to document the > > > > change over. Turns out that people compile their own kernels > > > > and do not necessarily turn this on. So, what do we do in that > > > case? > > > I thought more about this. > > > > > > How about a check in rc.sysinit to see if the kernel supports > > > capabilities? > > > > > > If the check fails it could do either or both of the following: > > > > > > 1. Display and log nasty warning message > > > 2. Run the command: chmod u+s `cat /etc/posixcapbinaries` > > I don't like self modifying systems. It can generate audit events and > cause aide to complain. Doing 1 above is fine of course. Should be the minimum. Regarding 2, I recognize that it isn't ideal, but it is probably better than the alternative (broken system). > > > Doing 2. would be the "friendly" thing to give the user a > > > non-broken system. It does make it a bit more complicated > > > because you'd want some logic that if they booted back to a > > > kernel with posix capabilities you stripped the suid bits. Also, > > rpm verity will complain. > > Another idea. > > > > Leave all the binaries with SUID bit set, but have the /etc/fstab > > have 'nosuid' on all the filesystems. > > The file system capabilities inside the kernel are treated as if they > were suid apps. IOW, nosuid also disables file system capabilities. That's too bad. Seems like that would be an elegant solution. No aid or rpm verify complaints since the filesystem itself isn't modified and compatibility with both types of kernels. Maybe worth separating suid and file system capabilities within the kernel in regards to the "nosuid" mount option. Dax Kelson -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
