Re: [PATCH] Exporting capability code/name pairs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is also the issue of compiled code which explicitly raises and lowers capabilities around critical code sections (ie., as they were intended to be used) is also not well served by this change. That is, unless the code was compiled with things like CAP_MAC_ADMIN being #define'd then it won't be able to do things like cap_set_flag() appropriately. Cheers Andrew KaiGai Kohei wrote: > Andrew Morgan wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> KaiGai Kohei wrote: >>> Remaining issues: >>> - We have to mount securityfs explicitly, or use /etc/fstab. >>> It can cause a matter when we want to use this feature on >>> very early phase on boot. (like /sbin/init) >> I'm not altogether clear how you intend this to work. >> >> Are you saying that some future version of libcap will require that >> securityfs be mounted before it (libcap) will work? > > Yes, but implementing this feature on securityfs might be not good > idea as as James said. If this feature is on procfs or sysfs, it is > not necessary to mount securityfs explicitly. > > Thanks, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfD7n+bHCR3gb8jsRAsgcAKDY6qXBR3JV2addHUg5sxyZHJEkDQCfdLOL zJlf3T4SQsUNENr3kwR5pr8= =v8C5 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Wed, Jan 02, 2008 at 06:26:07PM +0100, Jan Engelhardt wrote: > > On Jan 2 2008 12:09, Eric Paris wrote: > > > >So in the end we are all happy with the original patch I sent? > > > No objections at least :) I agree too. BTW, I've intentionally not merged it into 2.4, I prefer that admins deliberately set the sysctl on their servers than using a kernel in which they forgot it was enabled. But I agree that for wider use, the kernel option will help a lot. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Jan 2 2008 12:09, Eric Paris wrote: > >So in the end we are all happy with the original patch I sent? > No objections at least :) - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Fri, 2007-12-21 at 23:59 +0100, Jan Engelhardt wrote: > On Dec 21 2007 14:35, Greg KH wrote: > >> >> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is > >> >> >base 10 as well > >> >> > >> >> sysfs is autobase, i.e. echo "0xb000" >/sys/foo will Do The Right Thing. > >> > > >> >yes but if you cat /proc/sys/vm/mmap_min_addr, it returns in base 10. > >> > >> sysfs should probably be tuned to output it in a preferred base. > > > >Again, this is sysctl, not sysfs. two very different things... > > > Argh... :) Just shows that /proc is the wrong place for system variables. > > Well, module_params(integer) are autobase, and that's all I needed so > far :-D So in the end we are all happy with the original patch I sent? -Eric - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/28] FS-Cache: Recruit a couple of page flags for cache management [try #2]
Nick Piggin <[EMAIL PROTECTED]> wrote: > Then make a PG_private2 bit and use that. To what end? Are you suggesting I should have: PG_private2 = PG_private | PG_fscache That's redundant information and doesn't help anything really. My suggestion (PG_private and PG_fscache separate and independent) is pretty efficient to actually render into machine instructions, especially if the two bits are placed in the lower part of the word. On x86, the test for both bits can be done with a single TEST instruction, and on most RISC archs, a MOVE and a single AND will usually suffice. David - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
James Morris <[EMAIL PROTECTED]> wrote: > I suspect it may be useful ensure all global identifiers for the key > subsystem are prefixed with key_, as 'copy_keys' does seem a little > generic. Many of the fork helpers are called copy_xxx(). David - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Exporting capability code/name pairs
On Wed, 2 Jan 2008, KaiGai Kohei wrote: > > Another issue is that securityfs depends on CONFIG_SECURITY, which might be > > undesirable, given that capabilities are a standard feature. > > We can implement this feature on another pseudo filesystems. > Do you think what filesystem is the best candidate? > I prefer procfs or sysfs instead. Sysfs makes more sense, as this information is system-wide and does not relate to specific processes. -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Exporting capability code/name pairs
Andrew Morgan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > KaiGai Kohei wrote: >> Remaining issues: >> - We have to mount securityfs explicitly, or use /etc/fstab. >> It can cause a matter when we want to use this feature on >> very early phase on boot. (like /sbin/init) > > I'm not altogether clear how you intend this to work. > > Are you saying that some future version of libcap will require that > securityfs be mounted before it (libcap) will work? Yes, but implementing this feature on securityfs might be not good idea as as James said. If this feature is on procfs or sysfs, it is not necessary to mount securityfs explicitly. Thanks, -- KaiGai Kohei <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Exporting capability code/name pairs
James Morris wrote:
On Fri, 28 Dec 2007, KaiGai Kohei wrote:
Remaining issues:
- We have to mount securityfs explicitly, or use /etc/fstab.
It can cause a matter when we want to use this feature on
very early phase on boot. (like /sbin/init)
Why can't early userspace itself mount securityfs?
Hmm,,,
It might be possible as load_policy() doing, if necessary.
Please forget the previous my opinion.
I'm not even sure this is a good idea at all. Existing capabilities will
never disappear, and, as with syscalls, it's probably up to userland to
handle new ones not existing.
When we use libcap built on older kernel for newer kernel, libcap cannot
handle newly added capabilities, because it is not exist on the build
environment.
Therefore, any available capabilities should be exported dynamically by the
kernel.
In any case, some more technical issues:
kernel/cap_names.sh generates the body of cap_entries[] array,
This needs to be in the scripts directory.
OK, it will be moved.
The generated header should be made idempotent (#ifdef wrapping), and also
include a warning that it is automatically generated (identifying the
script which does so), and that is should not be edited.
+ d_caps = securityfs_create_dir("capability", NULL);
+ if (!d_caps)
Wrong way to check for error -- the function returns an ERR_PTR().
+ f_caps[i] = securityfs_create_file(cap_entries[i].name, 0444,
+ d_caps, &cap_entries[i],
+ &cap_entry_fops);
+ if (!f_caps[i])
Ditto.
OK,
Another issue is that securityfs depends on CONFIG_SECURITY, which might
be undesirable, given that capabilities are a standard feature.
We can implement this feature on another pseudo filesystems.
Do you think what filesystem is the best candidate?
I prefer procfs or sysfs instead.
Thanks,
--
KaiGai Kohei <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
