[PATCH] Security: constify function pointer tables and fields
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
include/linux/security.h |2 +-
security/keys/proc.c |4 ++--
security/selinux/selinuxfs.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index ac05083..c41e132 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2266,7 +2266,7 @@ static inline struct dentry *securityfs_create_file(const
char *name,
mode_t mode,
struct dentry *parent,
void *data,
- struct file_operations *fops)
+ const struct file_operations
*fops)
{
return ERR_PTR(-ENODEV);
}
diff --git a/security/keys/proc.c b/security/keys/proc.c
index 3e0d0a6..6941260 100644
--- a/security/keys/proc.c
+++ b/security/keys/proc.c
@@ -26,7 +26,7 @@ static void *proc_keys_next(struct seq_file *p, void *v,
loff_t *_pos);
static void proc_keys_stop(struct seq_file *p, void *v);
static int proc_keys_show(struct seq_file *m, void *v);
-static struct seq_operations proc_keys_ops = {
+static const struct seq_operations proc_keys_ops = {
.start = proc_keys_start,
.next = proc_keys_next,
.stop = proc_keys_stop,
@@ -47,7 +47,7 @@ static void *proc_key_users_next(struct seq_file *p, void *v,
loff_t *_pos);
static void proc_key_users_stop(struct seq_file *p, void *v);
static int proc_key_users_show(struct seq_file *m, void *v);
-static struct seq_operations proc_key_users_ops = {
+static const struct seq_operations proc_key_users_ops = {
.start = proc_key_users_start,
.next = proc_key_users_next,
.stop = proc_key_users_stop,
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 2fa483f..397fd49 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -1222,7 +1222,7 @@ static int sel_avc_stats_seq_show(struct seq_file *seq,
void *v)
static void sel_avc_stats_seq_stop(struct seq_file *seq, void *v)
{ }
-static struct seq_operations sel_avc_cache_stats_seq_ops = {
+static const struct seq_operations sel_avc_cache_stats_seq_ops = {
.start = sel_avc_stats_seq_start,
.next = sel_avc_stats_seq_next,
.show = sel_avc_stats_seq_show,
--
1.5.3.4
-
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: POSIX file capabilities for directories
On Dec 26 2007 16:29, Andrew Morgan wrote: >> >> I'm assuming it's unintended - or rather it's harmless but has no use - >> but will let Andrew respond since he may have some cool idea i haven't >> thought of. > >This is not intended behavior. It should be fixed (aka such support >removed). Capabilities should only be available on executable files - >not directories, symlinks or anything else... > What about defining Windows-style access control, e.g. splitting up the +w bit into "append (create new files)" and "delete files"? - 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 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 - 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 Dec 21 2007 22:16, Willy Tarreau wrote: >Hi Jan, > >> >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR >> >> >+int "Low address space to protect from user allocation" >> >> >> >> Hm, should not this be 'hex'? >> > >> >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. - 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 Dec 21 2007 15:31, Eric Paris wrote: >On Thu, 2007-12-20 at 00:29 +0100, Jan Engelhardt wrote: >> On Dec 19 2007 16:59, Eric Paris wrote: >> > >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR >> >+int "Low address space to protect from user allocation" >> >> Hm, should not this be 'hex'? > >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. >so I figured consistency was a good thing. Do you have >strong feelings? I guess so since you posted about it. - 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 Dec 19 2007 16:59, Eric Paris wrote: > >+config SECURITY_DEFAULT_MMAP_MIN_ADDR >+int "Low address space to protect from user allocation" Hm, should not this be 'hex'? >+depends on SECURITY >+default 0 >+help - 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] Smackv9: Use a stateful parser for parsing Smack rules
On Nov 1 2007 17:54, Ahmed S. Darwish wrote:
>+
>+static inline int isblank(char c)
>+{
>+ return (c == ' ' || c == '\t');
>+}
Use isspace().
>+ for (i = 0; i < count && data[i]; i ++)
>...
>+ subjectstr[(*label_len) ++] = data[i];
i++ w/o space
-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Nov 1 2007 12:51, Peter Dolding wrote: > >This is above me doing code. No matter how many fixes I do to the >core that will not fix dysfunction in the LSM section. Strict >policies on fixing the main security model will be required. If there is no one wanting to fix the existing code, then the perceived problem is not a problem. Or to put it another way: "You talk the talk, but do you also walk the walk?" - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 30 2007 12:14, Casey Schaufler wrote: > >while others including SELinux will go their own ways. So long >as LSMs are self contained and strictly restrictive the >mechanisms they use to modulate their behavior shouldn't be an >issue. If SELinux chooses to turn its MLS controls off between >midnight and 3am I can't see how that would be Smack's business, >even if they were somehow stacked. Multiple LSMs has issues, >like what should security_secid_to_secctx() return to the audit >system, but privilege model shouldn't be one of them. I am with you on that. And for everybody who missed it: MultiAdmin only grants rights at the same time commoncap does (e.g. on setuid and bprm_set_security). And all modules DO work with commoncap, now don't they? - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
(please do not drop Cc, or I would have lost this thread part if I had not been on lkml. And sometimes I am not because of the volume. Thanks.) On Oct 30 2007 15:13, Peter Dolding wrote: >On 10/30/07, Crispin Cowan <[EMAIL PROTECTED]> wrote: > >> * I have no clue what family to put MultiADM or Dazuko into > >MultiADMIN falls under o my god head ache. This is more a posix >standard feature altered ie 1 root user turned into many. This really >risks breaking the other models as a LSM. I disagree. Traditionally, Linux has given a process all capabilities when the UID changed to 0 (either by setuid(2) or executing a SUID binary). This has been relieved over the years, and right now with LSMs in the field, it is possible to 'deactivate' this special case for UID 0. SELinux does not have this special case for UID 0. Neither does it seem to use capabilities (quick grep through the source). So basically, all users are the same, and no one has capabilities by default. Does SELinux thus break with other LSMs? Now assume a SELinux system where all users have all capabilities (and the policy that is in place restricts the use of these capabilities then) -- should not be that unlikely. Does that break with other LSMs? - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 30 2007 01:50, Crispin Cowan wrote: >Jan Engelhardt wrote: >> Apparmor tutorial (beats any FAQ at first): >> ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi >> >Thanks for the high praise. Unfortunately that FTP site seems to not be >working. Some alternatives: [...] Actually, if the selinux team would do the same [introductionary video], I'd guess the hardness level commonly associated with selinux could be relieved a bit. - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 30 2007 12:23, Toshiharu Harada wrote: > > Instead of pushing TOMOYO Linux, I started developing > comparison chart of security-enhance Linux implementations. > The current version can be found in > > http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison Smack Security Model: autolabel, as far as I can tell. Smack Policy Generation: user - hand - and an editor Apparmor tutorial (beats any FAQ at first): ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi - 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: Out-of-tree modules [was: Linux Security *Module* Framework]
On Oct 29 2007 20:46, Lee Revell wrote: >On 10/29/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: >> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/ >> >> Provides a /dev/dsp style node for legacy applications that support >> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound. >> > >(I think that should read "AND more than 2 channel sound") It is for programs that only give out 2 channels of audio data. Qdsp_dpl2 is a node that applies the DPL2 matrix on these two channels, yielding the rear 2 channels, giving some sort of surround effect. >Couldn't ALSA's OSS emulation be extended to support more than 2 >channels per device node? I figured that exceeded my skills at that time. >> thkd - >> ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff >> >> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after >> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 ) > >It looks like this could be trivially fixed in a mergeable way. That >LKML thread petered out before the problem was seriously analyzed. > >Did you try the -Z flag of hdparm? IIRC, yes, been through all sorts of hdparm options. -Z did not help at all, and -B only prolonged the delay from 5 to around 15 seconds. I contacted Tosh Corp (before posting on lkml) and while they know of the 'issue', I did not get a satisfactory answer (namely how to FIX it), so I thought why spend time slapping if there's a workaround... Causing a minimal head seek every now and then (4096 bytes per 3 seconds is a somewhat small block size with a not-too-low interval) is a working workaround for now. The module code is not top notch, but I doubt I'll ever have more than one 1.8" MK2003GAH disk in the same laptop. - 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
Out-of-tree modules [was: Linux Security *Module* Framework]
On Oct 25 2007 19:56, Greg KH wrote: >What kind of code is not accepted into the mainline kernel tree for good >reasons? What are these reasons? What specific code are you talking >about? > >I'm trying to compile a list of all known external modules and drivers >and work to get them included in the main kernel tree to help prevent >these kinds of things. If you know of any that are not on the list at: > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers >please feel free to add them, or email me with the needed information >and I will add them to the list. quad_dsp - http://jengelh.hopto.org/p/quad_dsp/ Provides a /dev/dsp style node for legacy applications that support neither ALSA nor the AOSS wrapper nor more-than-2-channel sound. thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 ) - 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: Linux Security *Module* Framework
On Oct 28 2007 20:42, Tilman Schmidt wrote:
>Am 27.10.2007 20:22 schrieb Pavel Machek:
>> Hi!
>>
>>> but require unreasonable interface changes. As people who care
>>> about security (y'all who are only from the LKML are excused) it
>>> is our obligation to look beyond the preconceived notions of what
>>> is and isn't secure. Security is subjective. It's how you feel
>>> about it.
>>
>> Hmm. So lets add automagic security module. It magically fixes
>> security holes, and you can feel good about it.
>
>Send patch.
Perfect security from threats that normally deliver via internet!
(And it is even one of these that benefit from being modular!)
#include
#include
#include
#include
static void cl(const char *name, const char *state)
{
const char *args[] = {"ip", "link", "set", name, state, NULL};
call_usermodehelper("/sbin/ip", (char **)args, NULL, UMH_NO_WAIT);
}
int __init automagic_security_init(void)
{
const struct net_device *dev;
for_each_netdev(&init_net, dev)
cl(dev->name, "down");
return 0;
}
void __exit automagic_security_exit(void)
{
const struct net_device *dev;
for_each_netdev(&init_net, dev)
cl(dev->name, "up");
return;
}
module_init(automagic_security_init);
module_exit(automagic_security_exit);
-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 25 2007 19:56, Greg KH wrote: > >I'm trying to compile a list of all known external modules and drivers >and work to get them included in the main kernel tree to help prevent >these kinds of things. If you know of any that are not on the list at: > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers >please feel free to add them, or email me with the needed information >and I will add them to the list. Do I have to at least try to submit it to LKML first before it is even considered for the OOT wiki page? :-) - 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: LSM conversion to static interface
As I read through LWN today, I noted the following comment,
http://lwn.net/Articles/255832/ :
Personally, I think it's absolutely essential to be able to
build a kernel with dynamic LSM. Whether we like it or not,
people do want to add in runtime loadable security modules for
things like virus scanners, and until upstream offers these
folks a viable alternative to LSM...well, they'll use it.
Which reminded me of the TuxGuardian LSM[1] - another of the real-world
uses to meet Linus's criteria? ("had examples of their real-world use to
step forward and explain their use")
In this specific project, LSM is used to collect up calls to bind() and
connect() and pass them to userspace, e.g. do it ZoneAlarm-style and
display a dialog window. Its codebase is probably not too up-to-date
(website says last change last April - but I guess that's a no-brainer
to update it).
[1] http://tuxguardian.sf.net/
-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 24 2007 18:02, David P. Quigley wrote: >> >> But an LSM needs to _explicitly_ call the next LSM's function. No >> one (just a minimal grep in linux-2.6/security/) besides SELinux >> does that today. So while you could load AppArmor ontop of >> MultiAdm, it would never be invoked. This is what is known as >> "sufficient" in PAM parlance. > >I would hate to think some module which is a subset of the >restrictiveness of another could override it because its >"sufficient". If that was the case I could load in a module which >just returns 0 for everything and make it "sufficient" bypassing >every other module. This also introduces ordering dependencies. If >you install MultiAdm before AppArmor or SELinux and make it >"sufficient" then you defeated the point of having AppArmor or >SELinux installed in the first place. If I had to run mtadm and aa alongside each other, I would put aa into the "secondary" LSM slot. A number of people have said by now that LSM is supposed to be a restrict-my-rights block of code. As such, I would put the special, tiny, give-me-rights code at the front so that it be executed first. This is what would be intended with mtadm. It really just gives you a few caps when switching to UID 900 (or whatever), just as Linux traditionally gives you full caps when switching to UID 0 (e.g. by executing setuid files). From there on, it is just restrictions, and the order in which LSMs restrict your actions is probably not so important as long as they do restrict it. Thankfully, Linux capabilities are so strangely designed that they actually become useful - they give you so much power that you _can_ only restrict things afterwards again :-) - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 24 2007 16:37, Serge E. Hallyn wrote: > >Or, a better example, a privileged program reads some sensitive data - >as allowed by multiadm, writes it to a file, but apparmor prevented it >from chowning the file to the right user before writing, Interesting find, I should pay attention to that :-) But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call the next LSM's function. No one (just a minimal grep in linux-2.6/security/) besides SELinux does that today. So while you could load AppArmor ontop of MultiAdm, it would never be invoked. This is what is known as "sufficient" in PAM parlance. SELinux OTOH is in "required" mode [again PAM-speak]. - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 24 2007 17:02, David P. Quigley wrote: >> >> There has been a feature in the security framework that probably did >> not get much attention. It looks like YAGNI first, but on a closer look, >> it becomes useful pretty quick - secondary_register. >> >> As more and more simple LSM plugins pop up, stacking/chaining by means >> of secondary_register becomes attractive again, especially if these LSMs >> target different actions. This is probably the most useful thing why >> the LSM interface should remain modular: >> >> # Secure my files >> modprobe apparmor >> # -*- assuming apparmor implemented secondaries -*- >> # Secure my ports >> modprobe portac >> # More rights to users >> modprobe multiadm >> # -*- whatever else comes along -*- >Apparmor wants to lock down some application, it gives the application >access to a particular port, and the minimal set of privileges needed to >execute the application. [...] >however we now have to compose this with AppArmor. So an administrator >runs into an error running his application. Is this because his user >isn't granted the proper escalated privileges? Is it because AppArmor >needs an extra rule to run the application? Of course, the example I gave assumed that each LSM had disjunctive features. Apparmor is primarily known for blocking file access, and portac for blocking bind(2). If one of these gets additionaly functionality, it would be nice that code gets combined so that tracking down the piece of code that caused a particular syscall to say nay is easier to pinpoint. >It could also be that our third module has blocked the application >because it determined that even though multiadm specified that the >user should have the elevated privileges to run the application that >user shouldn't be able to bind to that port. >[...] Stacking works in things such as file systems because we have >a clearly defined interface with fixed solid semantics. You could >attempt to do that but once you have modules that step on each >others toes you have to figure out a way to reconcile that. I agree - if one does not get the magic behind LSM stacking, s/he should not use it, or learn to use it. However, if you grasp how it works (probably even easier to learn than figuring out how to selinux), one should know that a pam_deny.so even after a pam_permit.so will lock you down. Yeah, it's like PAM stacking. - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 24 2007 13:18, Crispin Cowan wrote: >Jan Engelhardt wrote: >> On Oct 24 2007 19:11, Simon Arlott wrote: >> >>> * (I've got a list of access rules which are scanned in order until one of >>> them matches, and an array of one bit for every port for per-port default >>> allow/deny - although the latter could be removed. >>> http://svn.lp0.eu/simon/portac/trunk/) >>> >> Besides the 'feature' of inhibiting port binding, >> is not this task of blocking connections something for a firewall? >> >So now you are criticizing his module. Arguing about the merits of >security semantics. This is exactly why Linus wanted LSM, so we don't >have to have these kinds of discussions, at least not on LKML :) This was a question. I was perfectly aware that iptables alone does not prohibit binding, and there are reasons to inhibit binding. But sometimes, a coder does not know where to start - chances are, that someone else wanting to do bind(2) inhibiting is doing it with a syscall table change. Or coder did not notice that a firewall is sufficient for the task to be achieved (which is not always the case - hence the question). - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 24 2007 19:59, Simon Arlott wrote: >On 24/10/07 19:51, Jan Engelhardt wrote: >> On Oct 24 2007 19:11, Simon Arlott wrote: >>> >>>* (I've got a list of access rules which are scanned in order until one of >>>them matches, and an array of one bit for every port for per-port default >>>allow/deny - although the latter could be removed. >>>http://svn.lp0.eu/simon/portac/trunk/) >> >> Besides the 'feature' of inhibiting port binding, >> is not this task of blocking connections something for a firewall? > >The firewall blocks incoming connections where appropriate, yes, but it >doesn't stop one user binding to a port that another user expected to be able >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports >below 1024 and it's useful to be able to prevent users from binding to them >too. Indeed. There has been a feature in the security framework that probably did not get much attention. It looks like YAGNI first, but on a closer look, it becomes useful pretty quick - secondary_register. As more and more simple LSM plugins pop up, stacking/chaining by means of secondary_register becomes attractive again, especially if these LSMs target different actions. This is probably the most useful thing why the LSM interface should remain modular: # Secure my files modprobe apparmor # -*- assuming apparmor implemented secondaries -*- # Secure my ports modprobe portac # More rights to users modprobe multiadm # -*- whatever else comes along -*- - 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: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Oct 24 2007 19:11, Simon Arlott wrote: > >* (I've got a list of access rules which are scanned in order until one of >them matches, and an array of one bit for every port for per-port default >allow/deny - although the latter could be removed. >http://svn.lp0.eu/simon/portac/trunk/) Besides the 'feature' of inhibiting port binding, is not this task of blocking connections something for a firewall? - 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] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
On Sep 30 2007 01:16, Andrew Morton wrote: >> >> Documentation/Smack.txt | 104 + >> security/Kconfig |1 >> security/Makefile |2 >> security/smack/Kconfig| 10 >> security/smack/Makefile |9 >> security/smack/smack.h| 207 ++ >> security/smack/smack_access.c | 345 >> security/smack/smack_lsm.c| 2685 >> security/smack/smackfs.c | 1201 ++ >> 9 files changed, 4564 insertions(+) > >My major non-technical concern is that Casey Schaufler might get hit by a >bus. If this happens, we can remove the feature in three minutes (that >diffstat again), but that may not be feasible if people have come to rely >upon the feature. > >otoh, if a significant number of people are using smack, presumably someone >else would step up to maintain smack post-bus. The risk seems acceptable >to me. I bet that the number of people submitting patches / possibly maintaining it is hyperbelic to the code size. Everyone that runs away from selinux's code size and/or "complexity" is a potential smack/aa user/contributor. >Is smack useful without a patched ls, sshd and init.d? What is the status >of getting those userspace patches merged? ie: do you know who to send the >diffs to, and are they likely to take them? As long as one does not need to recompile userspace (like it is the case with libselinux), it wins. - 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] Version2 Smack: Simplified Mandatory Access Control Kernel
On Aug 27 2007 23:59, Thomas Bleher wrote:
>> + for (cp = data - 1; cp != NULL; cp = strchr(cp + 1, '\n')) {
>> + if (*++cp == '\0')
>> + break;
>> + if (sscanf(cp, "%14s %30s\n", name, target) != 2) {
>> + printk("%s:%d bad scan\n",
>> + __func__, __LINE__);
>
>Leftover debugging printk? Otherwise, a level would be nice.
Or even pr_debug.
(pr_debug("%s...
>> +static struct tree_descr smack_files[] = {
Hey, can we make this const, if it does not change at runtime?
Jan
--
-
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] Smack: Simplified Mandatory Access Control Kernel
On Aug 22 2007 11:47, Casey Schaufler wrote:
>> As we have to maintain selinux, anyway, I don't see why simplification
>> layer is a problem.
>
>It's an issue if you want to do simple things, have the resources to
>do simple things, but go over budget because the simple things are
>built on top of complex things that you don't need. I see this crop
>up frequently with IT infrastructures, where simple problems get
>solved using completely unnecessary components just because those
>components are available.
class LinkedList {} for example. Just look how simple the linux
kernel does it ;-)
Jan
--
-
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] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 16:22, Casey Schaufler wrote:
>> >@@ -0,0 +1,8 @@
>> >+#
>> >+# Makefile for the SMACK LSM
>> >+#
>> >+
>> >+obj-$(CONFIG_SECURITY_SMACK) := smack.o
>> >+
>> >+smack-y := smack_lsm.o smack_access.o smackfs.o
>>
>> smack-objs :=
>
>Added.
I should have added "replace it".
>> >+/*
>> >+ * ' \n\0'
>> >+ */
>>
>> I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
>> uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
>> are actually meant as a char[8]? (/me scrathces head)
>
>Yes. "s == o" vs "strcmp(s,o) == 0".
Evil optimization ;-)
[ s == o is memcmp(s, o, sizeof(that)) == 0]
>> >+ char temp[80];
>> >+ ssize_t rc;
>> >+
>> >+ if (*ppos != 0)
>> >+ return 0;
>> >+
>> >+ sprintf(temp, "%d", smk_cipso_doi_value);
>> >+ rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
>>
>> 80 is plenty for a 11 char string.
>>
>> Look, they've got funny ideas! :)
>> net/ipv4/netfilter/nf_nat_irc.c:char buffer[sizeof("4294967296 65635")];
Proposal would have been: char temp[sizeof("4294967296")];
>> >+extern int smack_net_nltype;
>> >+extern int smack_cipso_direct;
>> >+extern struct smk_cipso_entry *smack_cipso;
>>
>> for consistency reasons, add extern to the other vars too...
>
>the others?
There were some [or some function prototypes] above this point.
>> >+static int smack_task_movememory(struct task_struct *p)
>> >+{
>> >+ int rc;
>> >+
>> >+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
>> >+ return rc;
>> >+}
>>
>> Uh...
>>
>> {
>> return smk_curacc(smk_of_task(p), MAY_WRITE);
>> }
>>
>> (also others)
>
>That was a little excessive, wasn't it?
How do you mean? I was just suggesting to collapse the three [four] lines into
one, getting rid of the tempotemporaries in a lot of these functions,
for example,
>> >+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
>> >+ int sig, u32 secid)
>> >+{
>> >+ smack_t *tsp = smk_of_task(p);
>> >+ int rc;
>> >+
>> >+ /*
>> >+* Sending a signal requires that the sender
>> >+* can write the receiver.
>> >+*/
>> >+ rc = smk_curacc(tsp, MAY_WRITE);
>> >+
>> >+ return rc;
>> >+}
static int smack_task_kill(struct stask_struct *p, struct siginfo *info,
int sig, u32 secid)
{
/* Comment */
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
Jan
--
-
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] Smack: Simplified Mandatory Access Control Kernel
On Aug 11 2007 10:57, Casey Schaufler wrote:
>
>"*" - pronounced "star"
wall
>"_" - pronounced "floor"
floor
>"^" - pronounced "hat"
roof
>"?" - pronounced "huh"
it's dark in here :)
>+config SECURITY_SMACK
>+ bool "Simplified Mandatory Access Control Kernel Support"
>+ depends on NETLABEL && SECURITY_NETWORK
Is this a hard dependency, or can this work without network sec labels?
>+ default n
>+ help
>+This selects the Simplified Mandatory Access Control Kernel.
>+SMACK is useful for sensitivity, integrity, and a variety
>+ of other madatory security schemes.
>+If you are unsure how to answer this question, answer N.
I smell broken tabs.
>+++ linux-2.6.22/security/smack/Makefile 2007-07-10 01:08:05.0
>-0700
>@@ -0,0 +1,8 @@
>+#
>+# Makefile for the SMACK LSM
>+#
>+
>+obj-$(CONFIG_SECURITY_SMACK) := smack.o
>+
>+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
>+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24 15:36:18.0
>-0700
>@@ -0,0 +1,113 @@
>+extern struct smk_list_entry *smack_list;
>+
>+static int smk_get_access(smack_t sub, smack_t obj)
>+{
>+ struct smk_list_entry *sp = smack_list;
proposes const struct. should be used elsewhere too.
>+ if (sub == SMK_STAR)
I just remember MechWarrior2 (game from Activison), where SMK stood for their
movie format... it's also a nice abbreviation for Seamonkey (browser suite).
>+ if (sub == SMK_HAT && ((request & MAY_ANYREAD) == request))
>+ return 0;
>+
>+ if (obj == SMK_FLOOR && ((request & MAY_ANYREAD) == request))
>+ return 0;
Redundant parentheses, be gone.
Never was it easier to say what ^ is called in your language :)
if (sub == '^' && ...)
return 0;
if (obj == '_' && ...)
>+/*
>+ * The value that this adds is that everything after any
>+ * character that's not allowed in a smack will be null
>+ */
>+smack_t smk_from_string(char *str)
>+{
>+ smack_t smack = 0LL;
"smack_t smack = 0;" is enough here.
>+ char *cp;
>+ int i;
>+
>+ for (cp = (char *)&smack, i = 0; i < sizeof(smack_t); str++,cp++,i++) {
Whatever it tries to do, this is not endian-safe. Except if @str
actually points to another smack_t. Yuck.
>+ if (*str <= ' ' || *str > '~')
>+ return smack;
>+ *cp = *str;
>+ }
>+ /*
>+ * Too long.
>+ */
>+ return SMK_INVALID;
>+}
>diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
>linux-2.6.22-base/security/smack/smackfs.c
>linux-2.6.22/security/smack/smackfs.c
>--- linux-2.6.22-base/security/smack/smackfs.c 1969-12-31 16:00:00.0
>-0800
>+++ linux-2.6.22/security/smack/smackfs.c 2007-07-24 21:51:30.0
>-0700
Can't securityfs and/or sysfs be used?
>+enum smk_inos {
>+ SMK_ROOT_INO = 2,
>+ SMK_LOAD = 3, /* load policy */
>+ SMK_LINKS = 4, /* symlinks */
>+ SMK_CIPSO = 5, /* load label -> CIPSO mapping */
>+ SMK_DOI = 6, /* CIPSO DOI */
>+ SMK_DIRECT =7, /* CIPSO level indicating direct label */
>+ SMK_AMBIENT = 8, /* internet ambient label */
>+ SMK_NLTYPE =9, /* label scheme to use by default */
>+ SMK_TMP = 100,/* MUST BE LAST! /smack/tmp */
>+};
Generally, =s are aligned too.
>+static struct smk_cipso_entry smack_cipso_floor = {
>+.smk_next = NULL,
>+.smk_smack = SMK_FLOOR,
>+.smk_level = 0,
>+.smk_catset = 0LL,
>+};
const me.
>+/*
>+ * ' \n\0'
>+ */
I wonder why it's limited to 8 characters? Ah right.. sizeof(smack_t).
uhm.. are you trying to tell me that smack_t [typedef'ed to u64]
are actually meant as a char[8]? (/me scrathces head)
>+ for (cp = result; slp != NULL; slp = slp->smk_next) {
>+ srp = &slp->smk_rule;
>+ sprintf(cp, "%-8s %-8s",
>+ (char *)&srp->smk_subject, (char *)&srp->smk_object);
I like (const char *).
>+ printk("%s:%d bad scan\n",
>+ __FUNCTION__, __LINE__);
__FUNCTION__ is a GNU extension, C99 uses __func__.
Not sure what they've got for __LINE__.
>+ if (strchr(modestr, 'r') || strchr(modestr, 'R'))
>+ rule.smk_access |= MAY_READ;
>+ if (strchr(modestr, 'w') || strchr(modestr, 'W'))
>+ rule.smk_access |= MAY_WRITE;
>+ if (strchr(modestr, 'x') || strchr(modestr, 'X'))
>+ rule.smk_access |= MAY_EXEC;
>+ if (strchr(modestr, 'a') || strchr(modestr, 'A'))
>+ rule.smk_access |= MAY_APPEND;
There's strpbrk() available for you.
>+static char *smk_digit(char *cp)
>+{
>+ for (; *cp != '\0'; cp++)
>+ if (*cp >= '0' && *cp <= '9')
>+ return cp;
>+
>+ return NUL
