Re: Problem with accessing namespace_sem from LSM.
On 11/6/2007 1:11 PM, Arjan van de Ven wrote: On Tue, 06 Nov 2007 13:00:41 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: Hello. I found that accessing namespace_sem from security_inode_create() causes lockdep warning when compiled with CONFIG_PROVE_LOCKING=y . sounds like you have an AB-BA deadlock... sed /you/AppArmor shipped with OpenSuSE 10.1 and 10.2/ :) Though I don't think this deadlock should occur quite often, it occurs when it occurs. Care should be taken promptly. There should be no way around for this problem as its nature. Passing vfsmount parameter to VFS helper functions and LSM hooks seems to be a good choice to me. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with accessing namespace_sem from LSM.
On 11/6/2007 1:11 PM, Arjan van de Ven wrote: On Tue, 06 Nov 2007 13:00:41 +0900 Tetsuo Handa [EMAIL PROTECTED] wrote: Hello. I found that accessing namespace_sem from security_inode_create() causes lockdep warning when compiled with CONFIG_PROVE_LOCKING=y . sounds like you have an AB-BA deadlock... sed /you/AppArmor shipped with OpenSuSE 10.1 and 10.2/ :) Though I don't think this deadlock should occur quite often, it occurs when it occurs. Care should be taken promptly. There should be no way around for this problem as its nature. Passing vfsmount parameter to VFS helper functions and LSM hooks seems to be a good choice to me. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
2007/10/31, Crispin Cowan <[EMAIL PROTECTED]>: > Peter Dolding wrote: > > Lets end the bitrot. Start having bits go into the main OS security > > features where they should be. > > > Linus categorically rejected this idea, several times, very clearly. > > He did so because the security community cannot agree on a > one-true-standard for what that OS security feature set should be. From > looking at this thread and many others, he is correct; there is no > consensus on what the feature set should be. > > So you can wish for the "main OS security features" all you want, but it > is not going to happen without a miraculous degree of consensus abruptly > arising. > > On the contrary, security, done well, is a tight fitting suit. It must > be tight, or it allows too much slack and attackers can exploit that. To > make it tight, it must be tailored to the situation at hand. That means > that there may *never* be a consensus on the "one true way", because it > could be that there is no "one true way". It could be that SMACK is best > in some cases, AppArmor in others, SELinux in others yet again, MLS in > others, etc. etc. > > I agree with Casey; LSM may not be perfect, but it is a great deal more > consensus than I have seen anywhere else in the security community. Your > desire that AppArmor and SELinux should share code has already happened: > LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and > TOMOYO, and MultiADM, etc. My main concern is whether we (different attempts) can share the code. IOW whether we can reach and form the agreement for single security framework. It is possible to write code if only we have a clear specifications, but this is not the case. I can easily think of LSM, or whatever we call, as Greatest Common Factor, but in that case LSM will explode soon and no single module can not be happy, Linux security will not be achieved. > It certainly can be improved, but it is not in need of wholesale > replacement, and especially not without a clear design that addresses > clearly stated problems that lots of people are having. We should not invent wheels, that is agreed by everyone , but if we try to share something that we can not share, we will fail. From the fact existing LSM did not satisfy any module (including SELinux), I do not want to investigate stack able version. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
2007/10/31, Crispin Cowan [EMAIL PROTECTED]: Peter Dolding wrote: Lets end the bitrot. Start having bits go into the main OS security features where they should be. Linus categorically rejected this idea, several times, very clearly. He did so because the security community cannot agree on a one-true-standard for what that OS security feature set should be. From looking at this thread and many others, he is correct; there is no consensus on what the feature set should be. So you can wish for the main OS security features all you want, but it is not going to happen without a miraculous degree of consensus abruptly arising. On the contrary, security, done well, is a tight fitting suit. It must be tight, or it allows too much slack and attackers can exploit that. To make it tight, it must be tailored to the situation at hand. That means that there may *never* be a consensus on the one true way, because it could be that there is no one true way. It could be that SMACK is best in some cases, AppArmor in others, SELinux in others yet again, MLS in others, etc. etc. I agree with Casey; LSM may not be perfect, but it is a great deal more consensus than I have seen anywhere else in the security community. Your desire that AppArmor and SELinux should share code has already happened: LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and TOMOYO, and MultiADM, etc. My main concern is whether we (different attempts) can share the code. IOW whether we can reach and form the agreement for single security framework. It is possible to write code if only we have a clear specifications, but this is not the case. I can easily think of LSM, or whatever we call, as Greatest Common Factor, but in that case LSM will explode soon and no single module can not be happy, Linux security will not be achieved. It certainly can be improved, but it is not in need of wholesale replacement, and especially not without a clear design that addresses clearly stated problems that lots of people are having. We should not invent wheels, that is agreed by everyone , but if we try to share something that we can not share, we will fail. From the fact existing LSM did not satisfy any module (including SELinux), I do not want to investigate stack able version. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On 10/30/2007 5:40 PM, Jan Engelhardt wrote: 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. I noticed the smell of danger in the naming of "Security Model". Please allow me some time. 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 Updated above two items. Thank you. :) I'm not an optimist to believe we can reach the perfect comparison. The purpose is to feed information, not to judge. This might sound ironically, but I don't really think we can *compare* them because they have different theories/purposes/backgrounds. Some kind of forgiveness and fuzziness are required. As I don't want to steal everybody's bandwidth, simple updates will be done silently. Your suggestions and information will be greatly appreciated despite of visible evidence. Thank you. Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On 10/30/2007 5:40 PM, Jan Engelhardt wrote: 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. I noticed the smell of danger in the naming of Security Model. Please allow me some time. 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 Updated above two items. Thank you. :) I'm not an optimist to believe we can reach the perfect comparison. The purpose is to feed information, not to judge. This might sound ironically, but I don't really think we can *compare* them because they have different theories/purposes/backgrounds. Some kind of forgiveness and fuzziness are required. As I don't want to steal everybody's bandwidth, simple updates will be done silently. Your suggestions and information will be greatly appreciated despite of visible evidence. Thank you. Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On 10/25/2007 9:41 AM, Chris Wright wrote: * Linus Torvalds ([EMAIL PROTECTED]) wrote: Do other people want to stand up and be "LSM maintainers" in the sense that they also end up being informed members who can also stand up for new modules and help merge them, rather than just push the existing one(s)? Chris? Casey? Crispin? Stephen and James, despite their clear bias towards SELinux, do try to give good feedback. But you are right, there's not enough active help for people trying to make a contribution to get their code in shape. Many of the modules that come along have been misguided conceptually, but I think that e.g. apparmor, tomoyo, smack could use that kind of constructive help to get into final mergable shape. Personally, I haven't spent nearly enough time reviewing those, my apologies to those developers. So, yes, help is welcome. Yes, TOMOYO Linux is committed to help. I mean, please count me in. PS Chris, I've been waiting for your comments for our code. :) Regards, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On 10/25/2007 10:42 AM, Casey Schaufler wrote: I agree that security code does need to provide security. What we need to get away from is the automatic attacks that are based on 20th century computer system assumptions. Things like "name based access control is rediculous", and "a module can't be any good if it doesn't deal with all objects", or "the granularity isn't fine enough". Look at TOMOYO. It's chuck full of good ideas. Why spend so much energy badgering them about not dealing with sockets? How about helping the AppArmor crew come up with acceptable implementations rather than whinging about the evils of hard links? And maybe, just maybe, we can get away from the inevitable claim that you could do that with a few minutes work in SELinux policy, but only if you're a security professional of course. Casey, Thank you introducing TOMOYO Linux. I really like your idea of simplified MAC (and you work so hard!). I also find advantages of AppArmor for distributing policies with less hustle. Finally and most importantly, I respect SELinux as the first in-tree, flexible and reliable security frame work and respect developers involved. As a project manager of TOMOYO Linux, I would like to push it, of course. But I noticed, if each of LSM module developer begin pushing their own code, that's not for the sake of Linux and we may end up with chaos. 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 I would like to receive feedbacks from Stephen, Crispin (you already have a comparison, though :), Casey and any people interested in. If possible, I would like to include opinions from BSD people. I would like LSM to be the result of common requirements. "Common" means good in general, but not always for security perspective. IMHO, I think it is possible for us to get to the conclusion not to have a framework. Cheers (and with love to Linux), Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On 10/25/2007 10:42 AM, Casey Schaufler wrote: I agree that security code does need to provide security. What we need to get away from is the automatic attacks that are based on 20th century computer system assumptions. Things like name based access control is rediculous, and a module can't be any good if it doesn't deal with all objects, or the granularity isn't fine enough. Look at TOMOYO. It's chuck full of good ideas. Why spend so much energy badgering them about not dealing with sockets? How about helping the AppArmor crew come up with acceptable implementations rather than whinging about the evils of hard links? And maybe, just maybe, we can get away from the inevitable claim that you could do that with a few minutes work in SELinux policy, but only if you're a security professional of course. Casey, Thank you introducing TOMOYO Linux. I really like your idea of simplified MAC (and you work so hard!). I also find advantages of AppArmor for distributing policies with less hustle. Finally and most importantly, I respect SELinux as the first in-tree, flexible and reliable security frame work and respect developers involved. As a project manager of TOMOYO Linux, I would like to push it, of course. But I noticed, if each of LSM module developer begin pushing their own code, that's not for the sake of Linux and we may end up with chaos. 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 I would like to receive feedbacks from Stephen, Crispin (you already have a comparison, though :), Casey and any people interested in. If possible, I would like to include opinions from BSD people. I would like LSM to be the result of common requirements. Common means good in general, but not always for security perspective. IMHO, I think it is possible for us to get to the conclusion not to have a framework. Cheers (and with love to Linux), Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On 10/25/2007 9:41 AM, Chris Wright wrote: * Linus Torvalds ([EMAIL PROTECTED]) wrote: Do other people want to stand up and be LSM maintainers in the sense that they also end up being informed members who can also stand up for new modules and help merge them, rather than just push the existing one(s)? Chris? Casey? Crispin? Stephen and James, despite their clear bias towards SELinux, do try to give good feedback. But you are right, there's not enough active help for people trying to make a contribution to get their code in shape. Many of the modules that come along have been misguided conceptually, but I think that e.g. apparmor, tomoyo, smack could use that kind of constructive help to get into final mergable shape. Personally, I haven't spent nearly enough time reviewing those, my apologies to those developers. So, yes, help is welcome. Yes, TOMOYO Linux is committed to help. I mean, please count me in. PS Chris, I've been waiting for your comments for our code. :) Regards, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WANTED: kernel projects for CS students
On 10/15/2007 8:01 AM, Rik van Riel wrote: > The kernel newbies community often gets inquiries from CS students who > need a project for their studies and would like to do something with > the Linux kernel, but would also like their code to be useful to the > community afterwards. > > In order to make it easier for them, I am trying to put together a > page with projects that: > - Are self contained enough that the students can implement the > project by themselves, since that is often a university requirement. > - Are self contained enough that Linux could merge the code (maybe > with additional changes) after the student has been working on it > for a few months. > - Are large enough to qualify as a student project, luckily there is > flexibility here since we get inquiries for anything from 6 week > projects to 6 month projects. > > If you have ideas on what projects would be useful, please add them > to this page (or email me): > > http://kernelnewbies.org/KernelProjects Well, I know something that might be interesting for kernel newbies including students. So let me share it with you. It's Ubuntu 7.04 based LiveCD with TOMOYO Linux kernel. Directions: 1. visit the following URL and save ISO image http://tomoyo.sourceforge.jp/wiki-e/?TomoyoLive 2. burn CD/DVD and boot from the disc (or start up VM from the downloaded image) 3. open "TOOMYO Linux Policy Editor" icon on the gnome desktop 4. browse "domains" with cursor keys you can see how processes were created (great experience) 5. choose a domain and enter return key you can see the behavior of the selected "domain" (ACL mode) 6. enter return to step 5 (domain transition mode) (repeat 5-7 as you like, type 'r' to refresh screen) 7. enter q to quit the editpolicy program As it's LiveCD like KNOPPIX, hard disks will not be affected unless you mount them and operate with intention. I mean, it's safe to play with. What makes all of these possible is "TOMOYO Linux", but you don't have to understand it. ;) No policy definition, preparation, knowledge or hustle is required. If you are interested in TOMOYO Linux (just in case...), please visit our Wiki page. http://tomoyo.sourceforge.jp/wiki-e/?WhatIs Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WANTED: kernel projects for CS students
On 10/15/2007 8:01 AM, Rik van Riel wrote: The kernel newbies community often gets inquiries from CS students who need a project for their studies and would like to do something with the Linux kernel, but would also like their code to be useful to the community afterwards. In order to make it easier for them, I am trying to put together a page with projects that: - Are self contained enough that the students can implement the project by themselves, since that is often a university requirement. - Are self contained enough that Linux could merge the code (maybe with additional changes) after the student has been working on it for a few months. - Are large enough to qualify as a student project, luckily there is flexibility here since we get inquiries for anything from 6 week projects to 6 month projects. If you have ideas on what projects would be useful, please add them to this page (or email me): http://kernelnewbies.org/KernelProjects Well, I know something that might be interesting for kernel newbies including students. So let me share it with you. It's Ubuntu 7.04 based LiveCD with TOMOYO Linux kernel. Directions: 1. visit the following URL and save ISO image http://tomoyo.sourceforge.jp/wiki-e/?TomoyoLive 2. burn CD/DVD and boot from the disc (or start up VM from the downloaded image) 3. open TOOMYO Linux Policy Editor icon on the gnome desktop 4. browse domains with cursor keys you can see how processes were created (great experience) 5. choose a domain and enter return key you can see the behavior of the selected domain (ACL mode) 6. enter return to step 5 (domain transition mode) (repeat 5-7 as you like, type 'r' to refresh screen) 7. enter q to quit the editpolicy program As it's LiveCD like KNOPPIX, hard disks will not be affected unless you mount them and operate with intention. I mean, it's safe to play with. What makes all of these possible is TOMOYO Linux, but you don't have to understand it. ;) No policy definition, preparation, knowledge or hustle is required. If you are interested in TOMOYO Linux (just in case...), please visit our Wiki page. http://tomoyo.sourceforge.jp/wiki-e/?WhatIs Cheers, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15] Conditional permission support.
Hi,
2007/8/25, Pavel Machek <[EMAIL PROTECTED]>:
> Hi!
>
> > This patch allows administrators use conditional permission.
> > TOMOYO Linux supports conditional permission based on
> > process's UID,GID etc. and/or requested pathname's UID/GID.
> >
> > Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
> > Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
>
> > + * Since the trailing spaces are removed by tmy_normalize_line(),
> > + * the last "\040if\040" sequence corresponds to condition part.
> > + */
> > +char *tmy_find_condition_part(char *data)
> > +{
> > + char *cp = strstr(data, " if ");
> > + if (cp) {
> > + char *cp2;
> > + while ((cp2 = strstr(cp + 3, " if ")) != NULL)
> > + cp = cp2;
> > + *cp++ = '\0';
> > + }
> > + return cp;
> > +}
> ...
>
> > + unsigned long left_min = 0;
> > + unsigned long left_max = 0;
> > + unsigned long right_min = 0;
> > + unsigned long right_max = 0;
> > + if (strncmp(condition, "if ", 3))
> > + return NULL;
> > + condition += 3;
> > + start = condition;
> > + while (*condition) {
> > + if (*condition == ' ')
> > + condition++;
> > + for (left = 0; left < MAX_KEYWORD; left++) {
> > + if (strncmp(condition, cc_keyword[left].keyword,
> > + cc_keyword[left].keyword_len))
> > + continue;
> > + condition += cc_keyword[left].keyword_len;
> > + break;
> > + }
> > + if (left == MAX_KEYWORD) {
> > + if (!tmy_parse_ulong(_min, ))
> > + goto out;
> > + counter++; /* body */
> > + if (*condition != '-')
> > + goto not_range1;
> > + condition++;
> > + if (!tmy_parse_ulong(_max, )
> > + || left_min > left_max)
> > + goto out;
> > + counter++; /* body */
> > +not_range1: ;
> > + }
> > + if (strncmp(condition, "!=", 2) == 0)
> > + condition += 2;
> > + else if (*condition == '=')
> > + condition++;
> > + else
> > + goto out;
> > + counter++; /* header */
> > + for (right = 0; right < MAX_KEYWORD; right++) {
> > + if (strncmp(condition, cc_keyword[right].keyword,
> > + cc_keyword[right].keyword_len))
> > + continue;
> > + condition += cc_keyword[right].keyword_len;
> > + break;
> > + }
>
> What is that? Language parser in kernel?
>
> Pavel
Key idea of TOMOYO Linux is to let each process to remember the program
(path) name. Names are stored in task struct and "appended" to the list when
execve is called.
An example of /usr/lib/cups/backend/lpd.
(picked up from
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos4.4/domain_policy.txt?v=policy-sample)
/etc/rc.d/init.d/cups (fork)
/sbin/initlog (fork)
/usr/sbin/cupsd (fork)
/bin/bash (fork)
/usr/lib/cups/backend/lpd (current process)
SELinux and other DTE implementations need domain definitions to work.
It is administrators task to design domains and name each domains.
TOMOYO Linux can be used as DTE MAC, but administrators don't
have to define and name domains. Because TOMOYO Linux
automatically defines domains and name them (from booting to
shutdown).
I wrote "TOMOYO Linux can be used as MAC", because
users can just view the domain transitions and analyze systems
with TOMOYO Linux. Or they can use TOMOYO Linux to
get logs with process invocation histories instead of a simple
program name.
TOMOYO Linux policy consists of path names and they are currently
handled as strings.
Thanks.
--
Toshiharu Harada
NTT DATA CORPORATION
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15] Conditional permission support.
Hi,
2007/8/25, Pavel Machek [EMAIL PROTECTED]:
Hi!
This patch allows administrators use conditional permission.
TOMOYO Linux supports conditional permission based on
process's UID,GID etc. and/or requested pathname's UID/GID.
Signed-off-by: Kentaro Takeda [EMAIL PROTECTED]
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
+ * Since the trailing spaces are removed by tmy_normalize_line(),
+ * the last \040if\040 sequence corresponds to condition part.
+ */
+char *tmy_find_condition_part(char *data)
+{
+ char *cp = strstr(data, if );
+ if (cp) {
+ char *cp2;
+ while ((cp2 = strstr(cp + 3, if )) != NULL)
+ cp = cp2;
+ *cp++ = '\0';
+ }
+ return cp;
+}
...
+ unsigned long left_min = 0;
+ unsigned long left_max = 0;
+ unsigned long right_min = 0;
+ unsigned long right_max = 0;
+ if (strncmp(condition, if , 3))
+ return NULL;
+ condition += 3;
+ start = condition;
+ while (*condition) {
+ if (*condition == ' ')
+ condition++;
+ for (left = 0; left MAX_KEYWORD; left++) {
+ if (strncmp(condition, cc_keyword[left].keyword,
+ cc_keyword[left].keyword_len))
+ continue;
+ condition += cc_keyword[left].keyword_len;
+ break;
+ }
+ if (left == MAX_KEYWORD) {
+ if (!tmy_parse_ulong(left_min, condition))
+ goto out;
+ counter++; /* body */
+ if (*condition != '-')
+ goto not_range1;
+ condition++;
+ if (!tmy_parse_ulong(left_max, condition)
+ || left_min left_max)
+ goto out;
+ counter++; /* body */
+not_range1: ;
+ }
+ if (strncmp(condition, !=, 2) == 0)
+ condition += 2;
+ else if (*condition == '=')
+ condition++;
+ else
+ goto out;
+ counter++; /* header */
+ for (right = 0; right MAX_KEYWORD; right++) {
+ if (strncmp(condition, cc_keyword[right].keyword,
+ cc_keyword[right].keyword_len))
+ continue;
+ condition += cc_keyword[right].keyword_len;
+ break;
+ }
What is that? Language parser in kernel?
Pavel
Key idea of TOMOYO Linux is to let each process to remember the program
(path) name. Names are stored in task struct and appended to the list when
execve is called.
An example of /usr/lib/cups/backend/lpd.
(picked up from
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos4.4/domain_policy.txt?v=policy-sample)
/etc/rc.d/init.d/cups (forkexec)
/sbin/initlog (forkexec)
/usr/sbin/cupsd (forkexec)
/bin/bash (forkexec)
/usr/lib/cups/backend/lpd (current process)
SELinux and other DTE implementations need domain definitions to work.
It is administrators task to design domains and name each domains.
TOMOYO Linux can be used as DTE MAC, but administrators don't
have to define and name domains. Because TOMOYO Linux
automatically defines domains and name them (from booting to
shutdown).
I wrote TOMOYO Linux can be used as MAC, because
users can just view the domain transitions and analyze systems
with TOMOYO Linux. Or they can use TOMOYO Linux to
get logs with process invocation histories instead of a simple
program name.
TOMOYO Linux policy consists of path names and they are currently
handled as strings.
Thanks.
--
Toshiharu Harada
NTT DATA CORPORATION
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Well, I crated a Wiki page. If it helps, please feel free to use it. I mean I would like people to add your issues here. It's wiki, so you are welcome to modify everything. http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES If ml is better, I have no objections. I just wanted to help discussion. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Thank you, Toshiharu Harada Chris Wright wrote: > * Chris Mason ([EMAIL PROTECTED]) wrote: >> I'm sure people there will have a different versions of events. The >> one part that was discussed was if pathname based security was >> useful, and a number of the people in the room (outside of >> novell) said it was. Now, it could be that nobody wanted to argue >> anymore, since most opinions had come out on one list or another by >> then. > > Indeed. The trouble is that's too high level compared with the actual > implementation details. AA is stalled because it has failed to get > VFS support for it's model. I don't see a nice way out unless it > changes it's notion of policy language (globbing is the tough one) > or gets traction to pass dentry/vfsmount all the way down. Paths are > completely relevant for security, esp. when considering the parent dir > and the leaf (as in forward lookup case). Retroactively creating the > full path is at the minimum ugly, and in the worst case can be insecure > (yes AA has taken many measures to mitigate that insecurity). > >> But as someone who doesn't use either SElinux or AA, I really hope >> we can get past the part of the debate where: >> >> while(1) >> AA) we think we're making users happy with pathname security >> SELINUX) pathname security sucks > > Yes. Please. Both parties are miserably failing the sanity test. > Doing the same thing over and over and expecting different results. > > AA folks: deal with the VFS issues that your patchset have in a palatable > way (which does not include passing NULL when it's inconvenient to > do otherwise). You've already missed an opportunity with Christoph's > suggestions for changes in NFS. I know you've considered many alternative > approaches and consistently hit dead ends. But please note, if you > have coded yourself into a corner because of your policy language, > that's your issue to solve, not ours. > > SELinux folks: do something useful rather than quibbling over the TCSEC > definition of MAC and AA's poor taste in marketing literature. Here's > some suggestions: > > 1) Make SELinux usable (it's *still* the number one complaint). While > this is a bit of a cheap shot, it really is one of the core reasons AA > advocates exist. > 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. > 3) Write an effective exploit against AA that demonstrates the fundamental > weakness of the model (better make sure it's not also an issue for > targetted policy). -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, waste of time is taking place here, but it's not for pathname-based MAC but for wrongly posted messages, I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is let's make progress and help each other to make Linux better. Thank you, Toshiharu Harada Chris Wright wrote: * Chris Mason ([EMAIL PROTECTED]) wrote: I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity). But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where: while(1) AA) we think we're making users happy with pathname security SELINUX) pathname security sucks Yes. Please. Both parties are miserably failing the sanity test. Doing the same thing over and over and expecting different results. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. SELinux folks: do something useful rather than quibbling over the TCSEC definition of MAC and AA's poor taste in marketing literature. Here's some suggestions: 1) Make SELinux usable (it's *still* the number one complaint). While this is a bit of a cheap shot, it really is one of the core reasons AA advocates exist. 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. 3) Write an effective exploit against AA that demonstrates the fundamental weakness of the model (better make sure it's not also an issue for targetted policy). -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, waste of time is taking place here, but it's not for pathname-based MAC but for wrongly posted messages, I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Well, I crated a Wiki page. If it helps, please feel free to use it. I mean I would like people to add your issues here. It's wiki, so you are welcome to modify everything. http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES If ml is better, I have no objections. I just wanted to help discussion. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is let's make progress and help each other to make Linux better. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
Stephen Smalley wrote: On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote: 2007/6/13, Stephen Smalley <[EMAIL PROTECTED]>: On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash Why can't you do this via SELinux domain transitions? That lets you do it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the "invocation history" aka call chain. For example, the above could be expressed in SELinux policy already as: domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. The above SELinux policy looks similar to the one I wrote, but that is not very true. Because in my example, path name corresponds to a file while local_shell_t are bound to multiple. I understand the advantages of label, but it needs to be translated to human understandable form of path name. So I think pathname based call chains are advantages for at least auditing and profiling. Well, not to get into a debate, but think about whether "/usr/sbin/sshd /bin/bash" and "/sbin/mingetty /bin/bash" is more understandable to an administrator than "remote shell" vs. "local shell" - the label-based approach lets you map the low-level detail of individual programs/pathnames to abstract equivalence classes that are more understandable, not less. Further, think about the advantages of being able to encode only the security-relevant invocations, not all of them. With our sample implmentation of "automated process invocation history tracking system" (or TOMOYO Linux, in short :)), no domain transition design and definition is needed. All you have to do is just run the kernel. So limiting to encode does not matter much. On a different note, from a quick look, it looks like TOMOYO is AppArmor + invocation history from a user perspective. Plus a wider range of controls in your original implementation, but your LSM implementation seems to be just getting started and only deals with files. So what's the case for having a whole separate security module vs. a small extension to AppArmor? The reason we cut off various MAC controls was to make the code as small as possible (we knew lkml readers are busy). If AA would merge the TOMOYO Linux's "automated proccess invocation history tracking system" and "real-time policy learning system", I would be fine. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
Stephen, Thank you for your interests and comment. I'm beginning to feel that you might be misunderstanding my message. Let me explain. Stephen Smalley wrote: On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: A couple of years ago, we tried to build a tool to generate SELinux policy (*1). To do that, we had to gather the access requests information. So we researched a profiling method and got to the idea of having a process to store its invocation history information (or ancestors). Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash "The idea": If we let process to inherit the name of its ancestors (usualy starts from /sbin/init), then Linux kernel will be able to know ancestors for each process. "Above examples" are: examples of how we can distinguish the same /bin/bash processes. Why can't you do this via SELinux domain transitions? That lets you do What do you mean by "this" here? I was not talking about MAC nor policy definitions. it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the "invocation history" aka call chain. For example, the above could be expressed in SELinux policy already as: I might have confused you and I am sorry for that. The above three lines are not TOMOYO Linux plicy. domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. In your SELinux policy examples, someone must write down them. To do that someone must know what will happen beforehands. But if you use TOMOYO Linux, you'll get domain transition information easily. The example of the result can be found here: http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/?v=policy-sample (choose whatever distribution and open the link for "domain_policy.txt") For example, from http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos4.4/domain_policy.txt?v=policy-sample#L4564 you will know: /bin/cp which was invoked from /usr/bin/makewhatis which was invoked from /etc/cron.weekly/00-makewhatis.cron which was invoked from /usr/bin/run-parts which was invoked from /bin/bash which was invoked from /usr/sbin/crond that /bin/cp process needs to read /dev/null, /etc/selinux/config, /proc/filesystems, and write /var/cache/man/whatis, and truncate /var/cache/man/whatis. We implemnted the above mentioned idea and TOMOYO Linux is a sample system which use distinguished process as a "domain". In some sense it is a system analyzing tool. Again, we intended to share the idea to people on the lkml. MAC (TOMOYO Linux) is just a sample. Any feedback will be appreciated. It seemed to us that this clarification would be familiar to users/administrators and could be used for various purposes. We did implement this by making use of the Linux's traditional fork & exec mechanisms, and built a pathname-based MAC using this implementation. We named the result as "TOMOYO Linux" and made it open source at SourceForge.jp (*2). TOMOYO Linux kernel keeps track of process invocation and distinguishes every different process invocation history as a "domain". TOMOYO Linux can accumulate the accesses requests for each domain. TOMOYO Linux has a utility called "ccstree". It prints the invocation history for each process in addition to the output of "pstree" command: [EMAIL PROTECTED] ~]# ccstree init (1) /sbin/init +- udevd (388) /sbin/udevd ... +- automount (1970) /etc/rc.d/init.d/autofs /usr/sbin/automount +- acpid (1993) /etc/rc.d/init.d/acpid /bin/bash /usr/sbin/acpid +- cupsd (2008) /etc/rc.d/init.d/cups /bin/bash /usr/sbin/cupsd +- sshd (2026) /usr/sbin/sshd +- sshd (2269) /usr/sbin/sshd +- bash (2271) /usr/sbin/sshd /bin/bash +- ccstree (15125) /usr/sbin/sshd /bin/bash /root/ccstools/ccstree (symbol, "" indicates a virtual base.) We had a presentation and a tutorial session of TOMOYO Linux version 1.4 at the ELC2007 (*3). Version 1.4.1 is the latest and has a rich set of MAC functions for files, networking, and capabilities and so on. For historical reasons, it is not using LSM or auditd. We decided to share this idea with the Linux community and totally rewrote the code. The result was TOMOYO Linux 2.0, which is now using LSM and auditd. To make discussion smooth, we cut off MAC functions other than for files. We are posting thi
Re: [RFC] TOMOYO Linux
Stephen, Thank you for your interests and comment. I'm beginning to feel that you might be misunderstanding my message. Let me explain. Stephen Smalley wrote: On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: A couple of years ago, we tried to build a tool to generate SELinux policy (*1). To do that, we had to gather the access requests information. So we researched a profiling method and got to the idea of having a process to store its invocation history information (or ancestors). Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash The idea: If we let process to inherit the name of its ancestors (usualy starts from /sbin/init), then Linux kernel will be able to know ancestors for each process. Above examples are: examples of how we can distinguish the same /bin/bash processes. Why can't you do this via SELinux domain transitions? That lets you do What do you mean by this here? I was not talking about MAC nor policy definitions. it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the invocation history aka call chain. For example, the above could be expressed in SELinux policy already as: I might have confused you and I am sorry for that. The above three lines are not TOMOYO Linux plicy. domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. In your SELinux policy examples, someone must write down them. To do that someone must know what will happen beforehands. But if you use TOMOYO Linux, you'll get domain transition information easily. The example of the result can be found here: http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/?v=policy-sample (choose whatever distribution and open the link for domain_policy.txt) For example, from http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos4.4/domain_policy.txt?v=policy-sample#L4564 you will know: /bin/cp which was invoked from /usr/bin/makewhatis which was invoked from /etc/cron.weekly/00-makewhatis.cron which was invoked from /usr/bin/run-parts which was invoked from /bin/bash which was invoked from /usr/sbin/crond that /bin/cp process needs to read /dev/null, /etc/selinux/config, /proc/filesystems, and write /var/cache/man/whatis, and truncate /var/cache/man/whatis. We implemnted the above mentioned idea and TOMOYO Linux is a sample system which use distinguished process as a domain. In some sense it is a system analyzing tool. Again, we intended to share the idea to people on the lkml. MAC (TOMOYO Linux) is just a sample. Any feedback will be appreciated. It seemed to us that this clarification would be familiar to users/administrators and could be used for various purposes. We did implement this by making use of the Linux's traditional fork exec mechanisms, and built a pathname-based MAC using this implementation. We named the result as TOMOYO Linux and made it open source at SourceForge.jp (*2). TOMOYO Linux kernel keeps track of process invocation and distinguishes every different process invocation history as a domain. TOMOYO Linux can accumulate the accesses requests for each domain. TOMOYO Linux has a utility called ccstree. It prints the invocation history for each process in addition to the output of pstree command: [EMAIL PROTECTED] ~]# ccstree init (1) kernel /sbin/init +- udevd (388) kernel /sbin/udevd ... +- automount (1970) kernel /etc/rc.d/init.d/autofs /usr/sbin/automount +- acpid (1993) kernel /etc/rc.d/init.d/acpid /bin/bash /usr/sbin/acpid +- cupsd (2008) kernel /etc/rc.d/init.d/cups /bin/bash /usr/sbin/cupsd +- sshd (2026) kernel /usr/sbin/sshd +- sshd (2269) kernel /usr/sbin/sshd +- bash (2271) kernel /usr/sbin/sshd /bin/bash +- ccstree (15125) kernel /usr/sbin/sshd /bin/bash /root/ccstools/ccstree (symbol, kernel indicates a virtual base.) We had a presentation and a tutorial session of TOMOYO Linux version 1.4 at the ELC2007 (*3). Version 1.4.1 is the latest and has a rich set of MAC functions for files, networking, and capabilities and so on. For historical reasons, it is not using LSM or auditd. We decided to share this idea with the Linux community and totally rewrote the code. The result was TOMOYO Linux 2.0, which is now using LSM and auditd. To make discussion smooth, we cut off MAC functions other than for files. We are posting this message because we believe that this process invocation history idea might
Re: [RFC] TOMOYO Linux
Stephen Smalley wrote: On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote: 2007/6/13, Stephen Smalley [EMAIL PROTECTED]: On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash Why can't you do this via SELinux domain transitions? That lets you do it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the invocation history aka call chain. For example, the above could be expressed in SELinux policy already as: domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. The above SELinux policy looks similar to the one I wrote, but that is not very true. Because in my example, path name corresponds to a file while local_shell_t are bound to multiple. I understand the advantages of label, but it needs to be translated to human understandable form of path name. So I think pathname based call chains are advantages for at least auditing and profiling. Well, not to get into a debate, but think about whether /usr/sbin/sshd /bin/bash and /sbin/mingetty /bin/bash is more understandable to an administrator than remote shell vs. local shell - the label-based approach lets you map the low-level detail of individual programs/pathnames to abstract equivalence classes that are more understandable, not less. Further, think about the advantages of being able to encode only the security-relevant invocations, not all of them. With our sample implmentation of automated process invocation history tracking system (or TOMOYO Linux, in short :)), no domain transition design and definition is needed. All you have to do is just run the kernel. So limiting to encode does not matter much. On a different note, from a quick look, it looks like TOMOYO is AppArmor + invocation history from a user perspective. Plus a wider range of controls in your original implementation, but your LSM implementation seems to be just getting started and only deals with files. So what's the case for having a whole separate security module vs. a small extension to AppArmor? The reason we cut off various MAC controls was to make the code as small as possible (we knew lkml readers are busy). If AA would merge the TOMOYO Linux's automated proccess invocation history tracking system and real-time policy learning system, I would be fine. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig wrote: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. TOMOYO Linux is a pathname-based MAC, that is true. But what that patch aimed for was sharing the idea of having Linux kernel to keep "process invocation history" information for each process. In that sense, TOMOYO Linux is just a sample implementation. Please take a look at the following message: http://lkml.org/lkml/2007/6/13/58 Best regards, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig wrote: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. TOMOYO Linux is a pathname-based MAC, that is true. But what that patch aimed for was sharing the idea of having Linux kernel to keep process invocation history information for each process. In that sense, TOMOYO Linux is just a sample implementation. Please take a look at the following message: http://lkml.org/lkml/2007/6/13/58 Best regards, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
Morris, thank you for your comment. 2007/6/14, James Morris <[EMAIL PROTECTED]>: On Thu, 14 Jun 2007, Toshiharu Harada wrote: > TOMOYO Linux has a mode called "learning" > in addition to "permissive" and "enforce". You can easily > get the TOMOYO Linux policy with learning mode that > SELinux does not have. Blindly generating security policy through observation of the system is potentially dangerous for many reasons. See <http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/> When I saw Russell Coker and showed him a demonstration of TOMOYO Linux, he told the same comment. Also after tracing an AppAmor's long thread, I'm convinced of the meaning of label base. That's why I don't think TOMOYO Linux as a replace of SELinux. "Professional policy (or reference policy)" makes sense to me. However it may be safe for audition and profiling purpose. Policy learning feature of TOMOYO Linux will help understanding the behavior of Linux boxes. That is my point. I will double check the link you showed me. Thank you. (It's wonderful to receive comments from you and Stephen!) Note that while SELinux does also have a similar capability with the audit2allow tool, it should be considered an expert tool, the output of which needs to be understood before use (as noted in its man page). Yes. But I remember Frank said "don't use it :-)" when he gave a presentation in Japan. > In addition, access control mode of > TOMOYO Linux can be managed for every difference domain. We have considered per-domain enforcing mode a couple of times in the past, but figured that it could be implemented via policy alone (e.g. run the task in a domain where all accesses are allowed and logged); and it would also be of limited usefulness because of the aforementioned problems with learning mode security policy. I'll reply this part in later. Thanks! Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
2007/6/14, Rik van Riel <[EMAIL PROTECTED]>: Toshiharu Harada wrote: > 2007/6/14, Rik van Riel <[EMAIL PROTECTED]>: > SELinux has a well designed robust and flexible functions. > So it should be used for everywhere. I understand it. > As you mentioned one can analyze the system (process) > behaviors from AVC logs. But the maintenance cost is not trivial. > > If logging with process context is the only purpose, > current TOMOYO Linux can do it with no hustle at all. Yes, but so does standard SELinux. You are making me curious: what does TOMOYO do that is not done by regular SELinux? Logging with process name, path name and contexts is already done. I must have missed some other TOMOYO feature in your initial email... I see SELinux can log with process name, path name and contexts, but "contexts" must be defined beforehand. TOMOYO Linux kernel does that with pathname, so no label definitions needed. You can confirm the process (domain) transitions any time and access occurred are clarified per domain basis automatically. Security context in TOMOYO Linux is represented and stored as a call chain and very intuitive. TOMOYO Linux has a mode called "learning" in addition to "permissive" and "enforce". You can easily get the TOMOYO Linux policy with learning mode that SELinux does not have. In addition, access control mode of TOMOYO Linux can be managed for every difference domain. -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
2007/6/14, Rik van Riel <[EMAIL PROTECTED]>: > So I think pathname based call chains are advantages for > at least auditing and profiling. SELinux audit logs (well, whatever is in /var/log/audit on my system) does show the path names of objects that fail to be accessed as well as the name and context of the processes trying to access them. This is with standard Fedora and RHEL installations. Thank you for your comment. SELinux has a well designed robust and flexible functions. So it should be used for everywhere. I understand it. As you mentioned one can analyze the system (process) behaviors from AVC logs. But the maintenance cost is not trivial. If logging with process context is the only purpose, current TOMOYO Linux can do it with no hustle at all. Installation takes just 15 minutes. Please think it as something like TOYOTA Prius. It's a compact and economical car. Volvo is known by its security, but we don't have to use only Volvo. TOMOYO Linux and its underlying idea are free and you don't have to find a garage. :-) Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
2007/6/13, Stephen Smalley <[EMAIL PROTECTED]>: On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: > Here are examples: > /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash > /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash > /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash Why can't you do this via SELinux domain transitions? That lets you do it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the "invocation history" aka call chain. For example, the above could be expressed in SELinux policy already as: domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. The above SELinux policy looks similar to the one I wrote, but that is not very true. Because in my example, path name corresponds to a file while local_shell_t are bound to multiple. I understand the advantages of label, but it needs to be translated to human understandable form of path name. So I think pathname based call chains are advantages for at least auditing and profiling. -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] TOMOYO Linux
Hello, A couple of years ago, we tried to build a tool to generate SELinux policy (*1). To do that, we had to gather the access requests information. So we researched a profiling method and got to the idea of having a process to store its invocation history information (or ancestors). Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash It seemed to us that this clarification would be familiar to users/administrators and could be used for various purposes. We did implement this by making use of the Linux's traditional fork & exec mechanisms, and built a pathname-based MAC using this implementation. We named the result as "TOMOYO Linux" and made it open source at SourceForge.jp (*2). TOMOYO Linux kernel keeps track of process invocation and distinguishes every different process invocation history as a "domain". TOMOYO Linux can accumulate the accesses requests for each domain. TOMOYO Linux has a utility called "ccstree". It prints the invocation history for each process in addition to the output of "pstree" command: [EMAIL PROTECTED] ~]# ccstree init (1) /sbin/init +- udevd (388) /sbin/udevd ... +- automount (1970) /etc/rc.d/init.d/autofs /usr/sbin/automount +- acpid (1993) /etc/rc.d/init.d/acpid /bin/bash /usr/sbin/acpid +- cupsd (2008) /etc/rc.d/init.d/cups /bin/bash /usr/sbin/cupsd +- sshd (2026) /usr/sbin/sshd +- sshd (2269) /usr/sbin/sshd +- bash (2271) /usr/sbin/sshd /bin/bash +- ccstree (15125) /usr/sbin/sshd /bin/bash /root/ccstools/ccstree (symbol, "" indicates a virtual base.) We had a presentation and a tutorial session of TOMOYO Linux version 1.4 at the ELC2007 (*3). Version 1.4.1 is the latest and has a rich set of MAC functions for files, networking, and capabilities and so on. For historical reasons, it is not using LSM or auditd. We decided to share this idea with the Linux community and totally rewrote the code. The result was TOMOYO Linux 2.0, which is now using LSM and auditd. To make discussion smooth, we cut off MAC functions other than for files. We are posting this message because we believe that this process invocation history idea might be a useful addition to Linux. Please take some time to see what this small piece of software can do with your own eyes. Your feedback will be greatly appreciated. If some of you are interested in TOMOYO Linux as a method for access control, please be advised to try full-featured version 1.4.1 (*4). It is quite easy to install and maintain TOMOYO Linux, but it should not be considered as a replacement of SELinux. All right, that's almost everything. Please visit the following URL for the code and documents: http://tomoyo.sourceforge.jp/wiki-e/ If you want to see the code first, then: http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/?v=linux-2.6.21.3-tomoyo-2.0 We will have a TOMOYO Linux BOF session at the OLS2007 (*5). Please come along and let's talk. Thank you. Toshiharu Harada (project manager) Tetsuo Handa (main architect, version 1 author) Kentaro Takeda (version 2.0 author) NTT DATA CORPORATION http://www.nttdata.co.jp/en/index.html *1) http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf *2) http://tomoyo.sourceforge.jp/ *3) http://www.celinux.org/elc2007/ http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations *4) http://tomoyo.sourceforge.jp/en/1.4.1/ *5) http://www.linuxsymposium.org/2007/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] TOMOYO Linux
Hello, A couple of years ago, we tried to build a tool to generate SELinux policy (*1). To do that, we had to gather the access requests information. So we researched a profiling method and got to the idea of having a process to store its invocation history information (or ancestors). Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash It seemed to us that this clarification would be familiar to users/administrators and could be used for various purposes. We did implement this by making use of the Linux's traditional fork exec mechanisms, and built a pathname-based MAC using this implementation. We named the result as TOMOYO Linux and made it open source at SourceForge.jp (*2). TOMOYO Linux kernel keeps track of process invocation and distinguishes every different process invocation history as a domain. TOMOYO Linux can accumulate the accesses requests for each domain. TOMOYO Linux has a utility called ccstree. It prints the invocation history for each process in addition to the output of pstree command: [EMAIL PROTECTED] ~]# ccstree init (1) kernel /sbin/init +- udevd (388) kernel /sbin/udevd ... +- automount (1970) kernel /etc/rc.d/init.d/autofs /usr/sbin/automount +- acpid (1993) kernel /etc/rc.d/init.d/acpid /bin/bash /usr/sbin/acpid +- cupsd (2008) kernel /etc/rc.d/init.d/cups /bin/bash /usr/sbin/cupsd +- sshd (2026) kernel /usr/sbin/sshd +- sshd (2269) kernel /usr/sbin/sshd +- bash (2271) kernel /usr/sbin/sshd /bin/bash +- ccstree (15125) kernel /usr/sbin/sshd /bin/bash /root/ccstools/ccstree (symbol, kernel indicates a virtual base.) We had a presentation and a tutorial session of TOMOYO Linux version 1.4 at the ELC2007 (*3). Version 1.4.1 is the latest and has a rich set of MAC functions for files, networking, and capabilities and so on. For historical reasons, it is not using LSM or auditd. We decided to share this idea with the Linux community and totally rewrote the code. The result was TOMOYO Linux 2.0, which is now using LSM and auditd. To make discussion smooth, we cut off MAC functions other than for files. We are posting this message because we believe that this process invocation history idea might be a useful addition to Linux. Please take some time to see what this small piece of software can do with your own eyes. Your feedback will be greatly appreciated. If some of you are interested in TOMOYO Linux as a method for access control, please be advised to try full-featured version 1.4.1 (*4). It is quite easy to install and maintain TOMOYO Linux, but it should not be considered as a replacement of SELinux. All right, that's almost everything. Please visit the following URL for the code and documents: http://tomoyo.sourceforge.jp/wiki-e/ If you want to see the code first, then: http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/?v=linux-2.6.21.3-tomoyo-2.0 We will have a TOMOYO Linux BOF session at the OLS2007 (*5). Please come along and let's talk. Thank you. Toshiharu Harada (project manager) Tetsuo Handa (main architect, version 1 author) Kentaro Takeda (version 2.0 author) NTT DATA CORPORATION http://www.nttdata.co.jp/en/index.html *1) http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf *2) http://tomoyo.sourceforge.jp/ *3) http://www.celinux.org/elc2007/ http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations *4) http://tomoyo.sourceforge.jp/en/1.4.1/ *5) http://www.linuxsymposium.org/2007/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
2007/6/13, Stephen Smalley [EMAIL PROTECTED]: On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash Why can't you do this via SELinux domain transitions? That lets you do it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the invocation history aka call chain. For example, the above could be expressed in SELinux policy already as: domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. The above SELinux policy looks similar to the one I wrote, but that is not very true. Because in my example, path name corresponds to a file while local_shell_t are bound to multiple. I understand the advantages of label, but it needs to be translated to human understandable form of path name. So I think pathname based call chains are advantages for at least auditing and profiling. -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
2007/6/14, Rik van Riel [EMAIL PROTECTED]: So I think pathname based call chains are advantages for at least auditing and profiling. SELinux audit logs (well, whatever is in /var/log/audit on my system) does show the path names of objects that fail to be accessed as well as the name and context of the processes trying to access them. This is with standard Fedora and RHEL installations. Thank you for your comment. SELinux has a well designed robust and flexible functions. So it should be used for everywhere. I understand it. As you mentioned one can analyze the system (process) behaviors from AVC logs. But the maintenance cost is not trivial. If logging with process context is the only purpose, current TOMOYO Linux can do it with no hustle at all. Installation takes just 15 minutes. Please think it as something like TOYOTA Prius. It's a compact and economical car. Volvo is known by its security, but we don't have to use only Volvo. TOMOYO Linux and its underlying idea are free and you don't have to find a garage. :-) Cheers, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
2007/6/14, Rik van Riel [EMAIL PROTECTED]: Toshiharu Harada wrote: 2007/6/14, Rik van Riel [EMAIL PROTECTED]: SELinux has a well designed robust and flexible functions. So it should be used for everywhere. I understand it. As you mentioned one can analyze the system (process) behaviors from AVC logs. But the maintenance cost is not trivial. If logging with process context is the only purpose, current TOMOYO Linux can do it with no hustle at all. Yes, but so does standard SELinux. You are making me curious: what does TOMOYO do that is not done by regular SELinux? Logging with process name, path name and contexts is already done. I must have missed some other TOMOYO feature in your initial email... I see SELinux can log with process name, path name and contexts, but contexts must be defined beforehand. TOMOYO Linux kernel does that with pathname, so no label definitions needed. You can confirm the process (domain) transitions any time and access occurred are clarified per domain basis automatically. Security context in TOMOYO Linux is represented and stored as a call chain and very intuitive. TOMOYO Linux has a mode called learning in addition to permissive and enforce. You can easily get the TOMOYO Linux policy with learning mode that SELinux does not have. In addition, access control mode of TOMOYO Linux can be managed for every difference domain. -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
Morris, thank you for your comment. 2007/6/14, James Morris [EMAIL PROTECTED]: On Thu, 14 Jun 2007, Toshiharu Harada wrote: TOMOYO Linux has a mode called learning in addition to permissive and enforce. You can easily get the TOMOYO Linux policy with learning mode that SELinux does not have. Blindly generating security policy through observation of the system is potentially dangerous for many reasons. See http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/ When I saw Russell Coker and showed him a demonstration of TOMOYO Linux, he told the same comment. Also after tracing an AppAmor's long thread, I'm convinced of the meaning of label base. That's why I don't think TOMOYO Linux as a replace of SELinux. Professional policy (or reference policy) makes sense to me. However it may be safe for audition and profiling purpose. Policy learning feature of TOMOYO Linux will help understanding the behavior of Linux boxes. That is my point. I will double check the link you showed me. Thank you. (It's wonderful to receive comments from you and Stephen!) Note that while SELinux does also have a similar capability with the audit2allow tool, it should be considered an expert tool, the output of which needs to be understood before use (as noted in its man page). Yes. But I remember Frank said don't use it :-) when he gave a presentation in Japan. In addition, access control mode of TOMOYO Linux can be managed for every difference domain. We have considered per-domain enforcing mode a couple of times in the past, but figured that it could be implemented via policy alone (e.g. run the task in a domain where all accesses are allowed and logged); and it would also be of limited usefulness because of the aforementioned problems with learning mode security policy. I'll reply this part in later. Thanks! Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/29, Kyle Moffett <[EMAIL PROTECTED]>: >>> But writing policy with labels are somewhat indirect way (I mean, >>> we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we >>> need a lot of work that is what I wanted to tell. >> >> I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I >> do that only when I actually think I mislabeled files. > > I believe what you wrote, but it may not be as easy for average > Linux users. As I said before, average Linux users should not be writing their own security policy. I have yet to meet an "average Linux user" who could reliably quote for me what the file permissions on the "/tmp" directory should be, or what the sticky bit was. A small percentage of average Linux system administrators don't get that right consistently, and if you don't understand the sticky bit then you should *definitely* not be controlling program permissions on a per- syscall basis. Thank you for your detailed and thoughtful explanation. Things are much clear now for me. Although your explanation was quite persuasive, I still have some concerns. Linux is now being used literately everywhere. As devices, technologies and Linux itself is evolving so quickly, I'm afraid the way you showed was right but could never meet the every goal perfectly. So some areas, including embedded and special distro I guess, there must be solutions and help for average level administrators. I think there are two ways to make secure systems. One is just you wrote: "ask it professionals" way, the other is "making practices". You might ask "how?" My answer to the question is pahtname-based systems such as AppAmor and TOMOYO Linux. They can't be compared to SELinux, but they should be considered to supplemental tools. At least they are helpful to analyze how Linux works. Tweeking SELinux policy is not easy but writing policies for them is relatively easy (I'm not talking about security here). Not everybody can be a professional administrators, but he/she can be a professional administrator of his/her system. I believe there must be solutions for non professional administrators. That's why we developed TOMOYO Linux (http://tomoyo.sourceforge.jp/) and so was AppArmor I guess. You might laugh, but we are doing this because we want to contribute to Linux and its community. :) Thanks, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/29, Kyle Moffett [EMAIL PROTECTED]: But writing policy with labels are somewhat indirect way (I mean, we need ls -Z or ps -Z). Indirect way can cause flaw so we need a lot of work that is what I wanted to tell. I don't really use ls -Z or ps -Z when writing SELinux policy; I do that only when I actually think I mislabeled files. I believe what you wrote, but it may not be as easy for average Linux users. As I said before, average Linux users should not be writing their own security policy. I have yet to meet an average Linux user who could reliably quote for me what the file permissions on the /tmp directory should be, or what the sticky bit was. A small percentage of average Linux system administrators don't get that right consistently, and if you don't understand the sticky bit then you should *definitely* not be controlling program permissions on a per- syscall basis. Thank you for your detailed and thoughtful explanation. Things are much clear now for me. Although your explanation was quite persuasive, I still have some concerns. Linux is now being used literately everywhere. As devices, technologies and Linux itself is evolving so quickly, I'm afraid the way you showed was right but could never meet the every goal perfectly. So some areas, including embedded and special distro I guess, there must be solutions and help for average level administrators. I think there are two ways to make secure systems. One is just you wrote: ask it professionals way, the other is making practices. You might ask how? My answer to the question is pahtname-based systems such as AppAmor and TOMOYO Linux. They can't be compared to SELinux, but they should be considered to supplemental tools. At least they are helpful to analyze how Linux works. Tweeking SELinux policy is not easy but writing policies for them is relatively easy (I'm not talking about security here). Not everybody can be a professional administrators, but he/she can be a professional administrator of his/her system. I believe there must be solutions for non professional administrators. That's why we developed TOMOYO Linux (http://tomoyo.sourceforge.jp/) and so was AppArmor I guess. You might laugh, but we are doing this because we want to contribute to Linux and its community. :) Thanks, Toshiharu Harada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>: On May 27, 2007, at 03:25:27, Toshiharu Harada wrote: > 2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>: How is that argument not trivially circular? "Foo has an assumption that foo-property is always properly defined and maintained." That could be said about *anything*: What I wanted to mention was the difficulties or efforts to make assumptions real. I never meant a circular argument, but if you felt so I apologize sincerely. >> If you can't properly manage your labels, then how do you expect >> any security at all? > > Please read my message again. I didn't say, "This can never be > achieved". I said, "This can not be easily achieved". So you said "(data labels) can not be easily achieved". My question for you is: How do you manage secure UNIX systems without standard UNIX permission bits? Also: If you have problems with data labels then what makes pathname based labels "easier"? If there is something that could be done to improve SELinux and make it more readily configurable then it should probably be done. Permission bits can be checked easily with "ls" command, but assuring the correctness of labels are not that easy. I'll try to explain. The correctness of the permission bit for a given file can be judged solely by the result of "ls" command. The correctness of the label, on the other hand, can't be judged without understanding of whole policy including domain transitions. (see the attached figure) I can imagine that once one get the complete SELinux policy, then it is able to modify and maintain it. I don't say making a complete SELinux policy is impossible, and actually you said you did it. But to be frank, I don't think you are the average level user at all. ;-) > I'm very interested in how you can know that you have the correct > object labeling (this is my point). Could you tell? I know that I have the correct object labeling because: Do you mind if I add this? 0) I understood the default policy and perfectly understand the every behavior of my system. this is where the difficulties exist. 1) I rewrote/modified the default policy to be extremely strict on the system where I wanted the extra security and hassle. 2) I ensured that the type transitions were in place for almost everything that needed to be done to administer the system. 3) I wrote a file-contexts file and relabeled *once* 4) I loaded the customized policy plus policy for restorecon and relabeled for the last time 5) I reloaded the customized policy without restorecon privileges and without the ability to reload the policy again. 6) I never reboot the system without enforcing mode. 7) If there are unexpected errors or files have incorrect labels, I have to get the security auditor to log in on the affected system and relabel the problematic files manually (rare occurrence which requires excessive amounts of paperwork). Thank you for the procedures. It's quite helpful. > I don't deny DAC at all. If we deny DAC, we can't live with Linux > it's the base. MAC can be used to cover the shortages of DAC and > Linux's simple user model, that's it. > > From security point of view, simplicity is always the virtue and > the way to go. Inode combined label is guaranteed to be a single > at any point time. This is the most noticeable advantage of label- > based security. I would argue that pathname-based security breaks the "simplicity is the best virtue (of a security system)" paradigm, because it attributes multiple potentially-conflicting labels to the same piece Every pathname-based security must provide the mechanism to prevent a conflicting/malicious access, otherwise it's junk. I have a question for you. With current implementation of SELinux, only one label can be assigned. But there are cases that one object can be used in different context, so I think it might help if SELinux would allow objects to have multiple labels. (I'm not talking about conflicts here) What do you think? > But writing policy with labels are somewhat indirect way (I mean, > we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we > need a lot of work that is what I wanted to tell. I don't really use "ls -Z" or "ps -Z" when writing SELinux policy; I do that only when I actually think I mislabeled files. I believe what you wrote, but it may not be as easy for average Linux users. Typically the SELinux-policy-development cycle is: 1) Modify and reload the policy 2) Relabel the affected files (either by hand or with some automated tool like restorecon) 3) Rerun the problem program or daemon 4) Examine the errors in the audit logs. If there are no errors and it works then you're finished. 5) Go back to step 1 and fix your policy Cheers, Toshiharu Harada <>
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, Kyle Moffett [EMAIL PROTECTED]: On May 27, 2007, at 03:25:27, Toshiharu Harada wrote: 2007/5/27, Kyle Moffett [EMAIL PROTECTED]: How is that argument not trivially circular? Foo has an assumption that foo-property is always properly defined and maintained. That could be said about *anything*: What I wanted to mention was the difficulties or efforts to make assumptions real. I never meant a circular argument, but if you felt so I apologize sincerely. If you can't properly manage your labels, then how do you expect any security at all? Please read my message again. I didn't say, This can never be achieved. I said, This can not be easily achieved. So you said (data labels) can not be easily achieved. My question for you is: How do you manage secure UNIX systems without standard UNIX permission bits? Also: If you have problems with data labels then what makes pathname based labels easier? If there is something that could be done to improve SELinux and make it more readily configurable then it should probably be done. Permission bits can be checked easily with ls command, but assuring the correctness of labels are not that easy. I'll try to explain. The correctness of the permission bit for a given file can be judged solely by the result of ls command. The correctness of the label, on the other hand, can't be judged without understanding of whole policy including domain transitions. (see the attached figure) I can imagine that once one get the complete SELinux policy, then it is able to modify and maintain it. I don't say making a complete SELinux policy is impossible, and actually you said you did it. But to be frank, I don't think you are the average level user at all. ;-) I'm very interested in how you can know that you have the correct object labeling (this is my point). Could you tell? I know that I have the correct object labeling because: Do you mind if I add this? 0) I understood the default policy and perfectly understand the every behavior of my system. this is where the difficulties exist. 1) I rewrote/modified the default policy to be extremely strict on the system where I wanted the extra security and hassle. 2) I ensured that the type transitions were in place for almost everything that needed to be done to administer the system. 3) I wrote a file-contexts file and relabeled *once* 4) I loaded the customized policy plus policy for restorecon and relabeled for the last time 5) I reloaded the customized policy without restorecon privileges and without the ability to reload the policy again. 6) I never reboot the system without enforcing mode. 7) If there are unexpected errors or files have incorrect labels, I have to get the security auditor to log in on the affected system and relabel the problematic files manually (rare occurrence which requires excessive amounts of paperwork). Thank you for the procedures. It's quite helpful. I don't deny DAC at all. If we deny DAC, we can't live with Linux it's the base. MAC can be used to cover the shortages of DAC and Linux's simple user model, that's it. From security point of view, simplicity is always the virtue and the way to go. Inode combined label is guaranteed to be a single at any point time. This is the most noticeable advantage of label- based security. I would argue that pathname-based security breaks the simplicity is the best virtue (of a security system) paradigm, because it attributes multiple potentially-conflicting labels to the same piece Every pathname-based security must provide the mechanism to prevent a conflicting/malicious access, otherwise it's junk. I have a question for you. With current implementation of SELinux, only one label can be assigned. But there are cases that one object can be used in different context, so I think it might help if SELinux would allow objects to have multiple labels. (I'm not talking about conflicts here) What do you think? But writing policy with labels are somewhat indirect way (I mean, we need ls -Z or ps -Z). Indirect way can cause flaw so we need a lot of work that is what I wanted to tell. I don't really use ls -Z or ps -Z when writing SELinux policy; I do that only when I actually think I mislabeled files. I believe what you wrote, but it may not be as easy for average Linux users. Typically the SELinux-policy-development cycle is: 1) Modify and reload the policy 2) Relabel the affected files (either by hand or with some automated tool like restorecon) 3) Rerun the problem program or daemon 4) Examine the errors in the audit logs. If there are no errors and it works then you're finished. 5) Go back to step 1 and fix your policy Cheers, Toshiharu Harada attachment: fig.png
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>: On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: > 2007/5/27, James Morris <[EMAIL PROTECTED]>: >> On Sat, 26 May 2007, Kyle Moffett wrote: >>> AppArmor). On the other hand, if you actually want to protect >>> the _data_, then tagging the _name_ is flawed; tag the *DATA* >>> instead. >> >> Bingo. >> >> (This is how traditional Unix DAC has always functioned, and is >> what SELinux does: object labeling). > > Object labeling (or labeled security) looks simple and straight > forward way, but it's not. > > (1) Object labeling has a assumption that labels are always > properly defined and maintained. This can not be easily achieved. That's a circular argument, and a fairly trivial one at that. Sorry Kyle, I don't think it's a trivial one. The opposite. If you can't properly manage your labels, then how do you expect any security at all? Please read my message again. I didn't say, "This can never be achieved". I said, "This can not be easily achieved". If you can't manage your "labels", then pathname- based security won't work either. This is analogous to saying "Pathname-based security has an assumption that path-permissions are always properly defined and maintained", which is equally obvious. Yes,! You got the point. Both label-based and pathname-based apporaches have the advantaes and difficluties. In that sense they are equal. That's what I wanted to say. Both approaches can be improved and even can be used combined to overcome the difficulties. Let's not fight against and think together, then we can make Linux better. If you can't achieve the first with reasonable security, then you probably can't achieve the second either. Also, if you can't manage correct object labeling then I'm very interested in how you are maintaining secure Linux systems without standard DAC. I'm very interested in how you can know that you have the correct object labeling (this is my point). Could you tell? I assume your best efforts end up with - have a proper fc definitions and guard them (this can be done) - executes relabeling as needed (best efforts) - hope everything work fine > (2) Also, assigning a label is something like inventing and > assigning a *new* name (label name) to objects which can cause flaws. I don't understand how assigning new attributes to objects "can cause flaws", nor what flaws those might be; could you elaborate further? In particular, I don't see how this is really all that more complicated than defining additional access control in apache .htaccess files. The principle is the same: by stacking multiple independent security-verification mechanisms (Classical UNIX DAC and Apache permissions) you can increase security, albeit at an increased management cost. You might also note that ".htaccess" files are yet another form of successful "label-based" security; the security context for a directory depends on the .htaccess "label" file found within. The *exact* same principles apply to SELinux: you add additional attributes backed by a simple and powerful state- machine. The cross-checks are lower-level than those from .htaccess files, but the principles are the same. I don't deny DAC at all. If we deny DAC, we can't live with Linux it's the base. MAC can be used to cover the shortages of DAC and Linux's simple user model, that's it. From security point of view, simplicity is always the virtue and the way to go. Inode combined label is guaranteed to be a single at any point time. This is the most noticeable advantage of label-based security. But writing policy with labels are somewhat indirect way (I mean, we need "ls -Z" or "ps -Z"). Indirect way can cause flaw so we need a lot of work that is what I wanted to tell. Cheers, Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, Kyle Moffett [EMAIL PROTECTED]: On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: 2007/5/27, James Morris [EMAIL PROTECTED]: On Sat, 26 May 2007, Kyle Moffett wrote: AppArmor). On the other hand, if you actually want to protect the _data_, then tagging the _name_ is flawed; tag the *DATA* instead. Bingo. (This is how traditional Unix DAC has always functioned, and is what SELinux does: object labeling). Object labeling (or labeled security) looks simple and straight forward way, but it's not. (1) Object labeling has a assumption that labels are always properly defined and maintained. This can not be easily achieved. That's a circular argument, and a fairly trivial one at that. Sorry Kyle, I don't think it's a trivial one. The opposite. If you can't properly manage your labels, then how do you expect any security at all? Please read my message again. I didn't say, This can never be achieved. I said, This can not be easily achieved. If you can't manage your labels, then pathname- based security won't work either. This is analogous to saying Pathname-based security has an assumption that path-permissions are always properly defined and maintained, which is equally obvious. Yes,! You got the point. Both label-based and pathname-based apporaches have the advantaes and difficluties. In that sense they are equal. That's what I wanted to say. Both approaches can be improved and even can be used combined to overcome the difficulties. Let's not fight against and think together, then we can make Linux better. If you can't achieve the first with reasonable security, then you probably can't achieve the second either. Also, if you can't manage correct object labeling then I'm very interested in how you are maintaining secure Linux systems without standard DAC. I'm very interested in how you can know that you have the correct object labeling (this is my point). Could you tell? I assume your best efforts end up with - have a proper fc definitions and guard them (this can be done) - executes relabeling as needed (best efforts) - hope everything work fine (2) Also, assigning a label is something like inventing and assigning a *new* name (label name) to objects which can cause flaws. I don't understand how assigning new attributes to objects can cause flaws, nor what flaws those might be; could you elaborate further? In particular, I don't see how this is really all that more complicated than defining additional access control in apache .htaccess files. The principle is the same: by stacking multiple independent security-verification mechanisms (Classical UNIX DAC and Apache permissions) you can increase security, albeit at an increased management cost. You might also note that .htaccess files are yet another form of successful label-based security; the security context for a directory depends on the .htaccess label file found within. The *exact* same principles apply to SELinux: you add additional attributes backed by a simple and powerful state- machine. The cross-checks are lower-level than those from .htaccess files, but the principles are the same. I don't deny DAC at all. If we deny DAC, we can't live with Linux it's the base. MAC can be used to cover the shortages of DAC and Linux's simple user model, that's it. From security point of view, simplicity is always the virtue and the way to go. Inode combined label is guaranteed to be a single at any point time. This is the most noticeable advantage of label-based security. But writing policy with labels are somewhat indirect way (I mean, we need ls -Z or ps -Z). Indirect way can cause flaw so we need a lot of work that is what I wanted to tell. Cheers, Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, James Morris <[EMAIL PROTECTED]>: On Sat, 26 May 2007, Kyle Moffett wrote: > AppArmor). On the other hand, if you actually want to protect the _data_, > then tagging the _name_ is flawed; tag the *DATA* instead. Bingo. (This is how traditional Unix DAC has always functioned, and is what SELinux does: object labeling). Object labeling (or labeled security) looks simple and straight forward way, but it's not. (1) Object labeling has a assumption that labels are always properly defined and maintained. This can not be easily achieved. (2) Also, assigning a label is something like inventing and assigning a *new* name (label name) to objects which can cause flaws. I'm not saying labeled security or SELinux is wrong. I just wanted to remind that the important part is the "process" not the "result". :-) -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, James Morris [EMAIL PROTECTED]: On Sat, 26 May 2007, Kyle Moffett wrote: AppArmor). On the other hand, if you actually want to protect the _data_, then tagging the _name_ is flawed; tag the *DATA* instead. Bingo. (This is how traditional Unix DAC has always functioned, and is what SELinux does: object labeling). Object labeling (or labeled security) looks simple and straight forward way, but it's not. (1) Object labeling has a assumption that labels are always properly defined and maintained. This can not be easily achieved. (2) Also, assigning a label is something like inventing and assigning a *new* name (label name) to objects which can cause flaws. I'm not saying labeled security or SELinux is wrong. I just wanted to remind that the important part is the process not the result. :-) -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Hi, 2007/5/24, James Morris <[EMAIL PROTECTED]>: I can restate my question and ask why you'd want a security policy like: Subject 'sysadmin' has: read access to /etc/shadow read/write access to /views/sysadmin/etc/shadow where the objects referenced by the paths are identical and visible to the subject along both paths, in keeping with your description of "policy may allow access to some locations but not to others" ? If I understand correctly, the original issue was whether to allow passing vfsmount to the inode_create LSM hook or not. Which is independent from AA or "pathname based MAC", I think. It is proven that Linux can be used without that change, however it is also clear that current LSM cause the ambiguities as AA people has explained. Clearing ambiguities is a obvious gain to Linux and will make benefits for auditing besides "pathname based MAC". So here's my opinion. If anybody can't explain clear reason (or needs) to keep these ambiguities unsolved, we should consider to merge the proposal. Thanks. -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Hi, 2007/5/24, James Morris [EMAIL PROTECTED]: I can restate my question and ask why you'd want a security policy like: Subject 'sysadmin' has: read access to /etc/shadow read/write access to /views/sysadmin/etc/shadow where the objects referenced by the paths are identical and visible to the subject along both paths, in keeping with your description of policy may allow access to some locations but not to others ? If I understand correctly, the original issue was whether to allow passing vfsmount to the inode_create LSM hook or not. Which is independent from AA or pathname based MAC, I think. It is proven that Linux can be used without that change, however it is also clear that current LSM cause the ambiguities as AA people has explained. Clearing ambiguities is a obvious gain to Linux and will make benefits for auditing besides pathname based MAC. So here's my opinion. If anybody can't explain clear reason (or needs) to keep these ambiguities unsolved, we should consider to merge the proposal. Thanks. -- Toshiharu Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
