Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: > > 1. Create /moldy at "_" > > 2. For each label you care about > >2a. Create /moldy/ > >2b. Set the label of /moldy/ to > > 3. ln -s /smack/tmp /tmp > > > 1. Create /moldy at "_" > > 2. For each label you care about > >2a. Create /moldy/ > >2b. Set the label of /moldy/ to > > 3. ln -s /smack/tmp.link /tmp > 4. mount --bind /moldy /smack/tmp > or add > /moldy /smack/tmp none bind,rw 0 2 > to /etc/fstab (same effect as (4)) > > Compare with your variant; the difference is in one argument of ln(1) and > one additional line in rc script or /etc/fstab. Sorry, but I don't buy > the "extra setup complexity" argument at all. What I'm confused about is how that results in a process labeled "foo" getting a different /tmp from a process labeled "bar". I guess I'll have to review your first post. > > It's the content of a symlink, and that can be just about anything > > and is not required to point to anything, which is one reason why > > I made that choice. If you don't have a /tmp, or can't write to the > > /tmp that exists, or have a /tmp that's a dangling symlink under > > any circumstances you may have an issue. That's true regardless of > > the presence or absense of /smack. All of the traditional mechanisms > > for dealing with /tmp in a chrooted or namespaced environment remain. > > It's not about symlink pointing to /smack/; it's about the place > where /smack/ itself points to. And _that_ can bloody well be > different in different chroots. Which is completely OK with me. > Look, if you allow to change where it goes, you certainly allow different > prefices on different boxen; moreover, admin can change it freely according > to his layout on given box. OTOH, you _can't_ have it different in different > chroots and changing it in one will affect all of them. See why that's a > problem? Yes, I can see that could be an unexpected behavior. > > It's in a symlink on the filesystem, and it doesn't have to be an > > absolute pathname, although since it's a symlink and the semantics > > for a symlink allow that be be absolute, relative, or dangling I > > don't see any reason to restrict it from being absolute. > > Fixed-contents symlink (with or without variable tail - it's irrelevant > here) is a bloody wrong tool for that kind of fs for the reasons described > above. I do not understand where the concept of Fixed-contents symlink comes from. Yes, "tmp" is initialized to "/moldy/", but that can be changed by writing to /smack/links. Please help me understand the what you mean by fixed-contents symlinks. > And if you go for "prefix should point to location on the same fs" > you can trivially configure the rest in userland (one line describing a > binding), leaving the kernel-side stuff with something like "userland > can ask for a pair of symlink and directory, having symlink resolve > to directory + " instead of your "userland can ask for a symlink > resolving to + ". And _that_ is chroot-neutral - you don't > need to do any extra work... > > > Could allowing multiple distinct mounts and symlink assignments > > of /smackfs address those issues? > > ... like that one. Leave it to normal userland mechanisms; it's a matter > of a single line in whatever script you are using to set chroot up and it > involves _way_ fewer caveats. > > That said, Alan's point still stands - if you don't get processes changing > context back and forth, you don't need anything at all - we already have > all we need for that kind of setups (and no, selinux is not involved ;-). Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: > 1. Create /moldy at "_" > 2. For each label you care about >2a. Create /moldy/ >2b. Set the label of /moldy/ to > 3. ln -s /smack/tmp /tmp > 1. Create /moldy at "_" > 2. For each label you care about >2a. Create /moldy/ >2b. Set the label of /moldy/ to > 3. ln -s /smack/tmp.link /tmp 4. mount --bind /moldy /smack/tmp or add /moldy /smack/tmp none bind,rw 0 2 to /etc/fstab (same effect as (4)) Compare with your variant; the difference is in one argument of ln(1) and one additional line in rc script or /etc/fstab. Sorry, but I don't buy the "extra setup complexity" argument at all. > It's the content of a symlink, and that can be just about anything > and is not required to point to anything, which is one reason why > I made that choice. If you don't have a /tmp, or can't write to the > /tmp that exists, or have a /tmp that's a dangling symlink under > any circumstances you may have an issue. That's true regardless of > the presence or absense of /smack. All of the traditional mechanisms > for dealing with /tmp in a chrooted or namespaced environment remain. It's not about symlink pointing to /smack/; it's about the place where /smack/ itself points to. And _that_ can bloody well be different in different chroots. Look, if you allow to change where it goes, you certainly allow different prefices on different boxen; moreover, admin can change it freely according to his layout on given box. OTOH, you _can't_ have it different in different chroots and changing it in one will affect all of them. See why that's a problem? > It's in a symlink on the filesystem, and it doesn't have to be an > absolute pathname, although since it's a symlink and the semantics > for a symlink allow that be be absolute, relative, or dangling I > don't see any reason to restrict it from being absolute. Fixed-contents symlink (with or without variable tail - it's irrelevant here) is a bloody wrong tool for that kind of fs for the reasons described above. And if you go for "prefix should point to location on the same fs" you can trivially configure the rest in userland (one line describing a binding), leaving the kernel-side stuff with something like "userland can ask for a pair of symlink and directory, having symlink resolve to directory + " instead of your "userland can ask for a symlink resolving to + ". And _that_ is chroot-neutral - you don't need to do any extra work... > Could allowing multiple distinct mounts and symlink assignments > of /smackfs address those issues? ... like that one. Leave it to normal userland mechanisms; it's a matter of a single line in whatever script you are using to set chroot up and it involves _way_ fewer caveats. That said, Alan's point still stands - if you don't get processes changing context back and forth, you don't need anything at all - we already have all we need for that kind of setups (and no, selinux is not involved ;-). - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: > > > > Because you throw "simple" out the window when you require userland > > > > assistance to perform this function. > > > > > > Any more than having /tmp replaced with a symlink? > > > > Yes. By the way, there's nothing that really requires that you > > use a /smack symlink if you don't want to. /tmp can still be a > > real directory, a mount point, a symlink to /var/tmp, or whatever > > else you want it to be if that suits your needs better. For the > > simplest scenarios /tmp -> /smack/tmp -> /moldy/ has every > > other scheme I've seen throughly beaten. > > And your point is? If you don't use it, you get exact same complexity > in both setups. Thank you for your patience. Let me see if I can get my point across. The intended Smack scenario: 1. Create /moldy at "_" 2. For each label you care about 2a. Create /moldy/ 2b. Set the label of /moldy/ to 3. ln -s /smack/tmp /tmp All processes are now redirected into the appropriate place regardless of how they come into being. It doesn't matter if the "session" starts from busybox, login, sshd, xdm, crontab, or out of an init script. > > > _What_ userland intervention? Mounting stuff under /smack/tmp and not > under > > > your /moldy? > > > > Who said anything about mounting under /moldy? I never did. > > Sigh... So put the binding into fstab and be done with that. Are you suggesting that /smack/tmp.link below is a mount point, and that appropriate directories get mounted there? 1. Create /moldy at "_" 2. For each label you care about 2a. Create /moldy/ 2b. Set the label of /moldy/ to 2c. mount --bind /moldy/ /smack/tmp.link/ 3. ln -s /smack/tmp.link /tmp > > > Having /tmp replaced with symlink to /smack/tmp.link instead > > > of replacing it with a symlink to /smack/tmp? > > > > > > Absolute paths in that kind of thing are _wrong_. You know where the > things > > > are on your fs. You don't know if anything else will be visible, let > alone > > > whether it will be at the same place in all chroots or namespaces. And > no, > > > you _can't_ make sure that fs is visible only in one place. No fs can or > > > has any business even trying. > > > > Is the objection that there is a default value coded in? > > Right now the main objection is about your lack of ability to read. Now you sound like my daughter. :-) > Which > part of "it can be mounted in different chroots/namespaces, therefore > having absolute paths doesn't work" is too hard to understand? It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. > No, it's not about having a default. Nuts. That would have made addressing your concern easy. > It's about keeping an absolute pathname in virtual fs, It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. > having all instances autosoddingmatically sharing it _and_ > having change attempt in any instance automatically affect all of them. > If you have that kind of sharing, don't pretend that your mechanism really > allows absolute pathnames. Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? I think it would, but as you pointed out earlier, my lack of ability to read may be clouding my understanding. Thank you. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox <[EMAIL PROTECTED]> wrote: > > An embedded system that does not have user logins but that does > > have applications that require separation, perhaps a moble communication > > device with application download capability, is just one example > > where the smack symlink implementation provides the required > > function without requiring application support. > > I don't see what is such a problem here. For your mobile example you'd > give the application download side its own /tmp via mount. > > Its actually better this is done in user space as its more flexible that > way and can be tuned arbitarily to meet interesting or bizarre real world > cases. I admit to being impressed by the wide variety of mount options currently available. In many cases this will be the best approach. /tmp is a typical use for a smack symlink, but not the only one. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: > > > Because you throw "simple" out the window when you require userland > > > assistance to perform this function. > > > > Any more than having /tmp replaced with a symlink? > > Yes. By the way, there's nothing that really requires that you > use a /smack symlink if you don't want to. /tmp can still be a > real directory, a mount point, a symlink to /var/tmp, or whatever > else you want it to be if that suits your needs better. For the > simplest scenarios /tmp -> /smack/tmp -> /moldy/ has every > other scheme I've seen throughly beaten. And your point is? If you don't use it, you get exact same complexity in both setups. > > _What_ userland intervention? Mounting stuff under /smack/tmp and not under > > your /moldy? > > Who said anything about mounting under /moldy? I never did. Sigh... So put the binding into fstab and be done with that. > > Having /tmp replaced with symlink to /smack/tmp.link instead > > of replacing it with a symlink to /smack/tmp? > > > > Absolute paths in that kind of thing are _wrong_. You know where the things > > are on your fs. You don't know if anything else will be visible, let alone > > whether it will be at the same place in all chroots or namespaces. And no, > > you _can't_ make sure that fs is visible only in one place. No fs can or > > has any business even trying. > > Is the objection that there is a default value coded in? Right now the main objection is about your lack of ability to read. Which part of "it can be mounted in different chroots/namespaces, therefore having absolute paths doesn't work" is too hard to understand? No, it's not about having a default. It's about keeping an absolute pathname in virtual fs, having all instances autosoddingmatically sharing it _and_ having change attempt in any instance automatically affect all of them. If you have that kind of sharing, don't pretend that your mechanism really allows absolute pathnames. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
> An embedded system that does not have user logins but that does > have applications that require separation, perhaps a moble communication > device with application download capability, is just one example > where the smack symlink implementation provides the required > function without requiring application support. I don't see what is such a problem here. For your mobile example you'd give the application download side its own /tmp via mount. Its actually better this is done in user space as its more flexible that way and can be tuned arbitarily to meet interesting or bizarre real world cases. Alan - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox <[EMAIL PROTECTED]> wrote: > > Absolute paths in that kind of thing are _wrong_. You know where the > things > > are on your fs. You don't know if anything else will be visible, let alone > > whether it will be at the same place in all chroots or namespaces. And no, > > you _can't_ make sure that fs is visible only in one place. No fs can or > > has any business even trying. > > What I don't understand here is why we need the hacks when we already > support sufficient mount magic to give each login session its own > private /tmp ? An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: > > > what > > > happens if we want it in two chroot jails with different layouts? > > > > As you can only have /smack mounted once, this isn't an issue, > > but it does present an interesting use case that brings the one > > mount limitation into question. I'll add addressing this to the > > short term todo list. > > Of course you can mount it more than once. Just bind the sucker and you > are done. > > > > I really don't get it; why not simply have something like > > > /smack/tmp.link resolve to tmp/ and have userland bind or mount > > > whatever you bloody like on /smack/tmp? > > > > Because you throw "simple" out the window when you require userland > > assistance to perform this function. > > Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp -> /smack/tmp -> /moldy/ has every other scheme I've seen throughly beaten. > > I'm having some trouble seeing how the 60 lines of code in > > smackfs dealing with symlinks would be improved by your suggestions. > > I certainly don't see how requiring userland intervention would > > do anything but make it bigger and less reliable. > > _What_ userland intervention? Mounting stuff under /smack/tmp and not under > your /moldy? Who said anything about mounting under /moldy? I never did. > Having /tmp replaced with symlink to /smack/tmp.link instead > of replacing it with a symlink to /smack/tmp? > > Absolute paths in that kind of thing are _wrong_. You know where the things > are on your fs. You don't know if anything else will be visible, let alone > whether it will be at the same place in all chroots or namespaces. And no, > you _can't_ make sure that fs is visible only in one place. No fs can or > has any business even trying. Is the objection that there is a default value coded in? Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 07:17:35PM +0100, Alan Cox wrote: > > Absolute paths in that kind of thing are _wrong_. You know where the things > > are on your fs. You don't know if anything else will be visible, let alone > > whether it will be at the same place in all chroots or namespaces. And no, > > you _can't_ make sure that fs is visible only in one place. No fs can or > > has any business even trying. > > What I don't understand here is why we need the hacks when we already > support sufficient mount magic to give each login session its own > private /tmp ? Presumably his context can change within a login session? If not, it's indeed simply worthless, absolute paths or not. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
> Absolute paths in that kind of thing are _wrong_. You know where the things > are on your fs. You don't know if anything else will be visible, let alone > whether it will be at the same place in all chroots or namespaces. And no, > you _can't_ make sure that fs is visible only in one place. No fs can or > has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: > > what > > happens if we want it in two chroot jails with different layouts? > > As you can only have /smack mounted once, this isn't an issue, > but it does present an interesting use case that brings the one > mount limitation into question. I'll add addressing this to the > short term todo list. Of course you can mount it more than once. Just bind the sucker and you are done. > > I really don't get it; why not simply have something like > > /smack/tmp.link resolve to tmp/ and have userland bind or mount > > whatever you bloody like on /smack/tmp? > > Because you throw "simple" out the window when you require userland > assistance to perform this function. Any more than having /tmp replaced with a symlink? > I'm having some trouble seeing how the 60 lines of code in > smackfs dealing with symlinks would be improved by your suggestions. > I certainly don't see how requiring userland intervention would > do anything but make it bigger and less reliable. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: > > > > From: Casey Schaufler <[EMAIL PROTECTED]> > > > > Smack is the Simplified Mandatory Access Control Kernel. > > > > Smack implements mandatory access control (MAC) using labels > > attached to tasks and data containers, including files, SVIPC, > > and other tasks. Smack is a kernel based scheme that requires > > an absolute minimum of application support and a very small > > amount of configuration data. > > I _really_ don't like what you are doing with these symlinks. > For one thing, you have no exclusion between reading the list > entries and modifying them. That's easy enough to fix. I'll do it. > For another... WTF is filesystem > making assumptions about the locations where the things are > mounted? I assume by this that you're objecting to the initialization of /smack/tmp to point to /moldy/. Over the years I've seen a number of cases where failure to set up /tmp result in unhappy consequences. If /tmp is anything other than a real directory on the root filesystem it is important that special care be taken for the case where things don't get set up right for some reason. By including a specific, if perhaps arbitrary, default it becomes easier to create a configuration that survives the unexpected. > Hell, even if you override your tmp symlink, Which is something that I expect virtually everyone to do. > what > happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. > I really don't get it; why not simply have something like > /smack/tmp.link resolve to tmp/ and have userland bind or mount > whatever you bloody like on /smack/tmp? Because you throw "simple" out the window when you require userland assistance to perform this function. > No problems with absolute > paths, can be used in chroot jails with whatever layouts, ditto for > namespaces, etc. and both symlink and directory get created at > the same time (by one name). Hell, if you keep a reference > to dentry of directory in the data associated with symlink, > you can simply switch nd->dentry to that, drop the old one > and grab the reference to page containing label and return > it via nd_set_link(). No need to play with allocations, strcat, > yadda, yadda. readlink() can stuff the ->d_name of the same > dentry plus / plus label directly into user buffer; again, no > allocations needed and works fine anywhere. I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wednesday 03 October 2007 12:45:42 am Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> Smack is the Simplified Mandatory Access Control Kernel.
>
> Smack implements mandatory access control (MAC) using labels
> attached to tasks and data containers, including files, SVIPC,
> and other tasks. Smack is a kernel based scheme that requires
> an absolute minimum of application support and a very small
> amount of configuration data.
>
> {snip}
>
> This patch includes changes made by Paul Moore <[EMAIL PROTECTED]>
> in support of a more comfortable interface to initialize the
> CIPSO code from within the kernel. The changes in the net directory
> are Pauls, as is the update to netlabel.h
My sign-off got lost when Casey smooshed the patch I sent him into the SMACK
mega-patch so I'll throw it back in the thread for accounting purposes.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
As for SMACK's use of NetLabel - it looks fine to me, especially now that
there is better preservation of the NetLabel/LSM boundary. As has been
discussed on the various lists during earlier revisions of the patch I
believe there are still some optimizations that can be made regarding how
SMACK uses NetLabel but that is something we can always work on at a later
date.
Acked-by: Paul Moore <[EMAIL PROTECTED]>
--
paul moore
linux security @ hp
-
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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wednesday 03 October 2007 12:45:42 am Casey Schaufler wrote:
From: Casey Schaufler [EMAIL PROTECTED]
Smack is the Simplified Mandatory Access Control Kernel.
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and other tasks. Smack is a kernel based scheme that requires
an absolute minimum of application support and a very small
amount of configuration data.
{snip}
This patch includes changes made by Paul Moore [EMAIL PROTECTED]
in support of a more comfortable interface to initialize the
CIPSO code from within the kernel. The changes in the net directory
are Pauls, as is the update to netlabel.h
My sign-off got lost when Casey smooshed the patch I sent him into the SMACK
mega-patch so I'll throw it back in the thread for accounting purposes.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
As for SMACK's use of NetLabel - it looks fine to me, especially now that
there is better preservation of the NetLabel/LSM boundary. As has been
discussed on the various lists during earlier revisions of the patch I
believe there are still some optimizations that can be made regarding how
SMACK uses NetLabel but that is something we can always work on at a later
date.
Acked-by: Paul Moore [EMAIL PROTECTED]
--
paul moore
linux security @ hp
-
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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: From: Casey Schaufler [EMAIL PROTECTED] Smack is the Simplified Mandatory Access Control Kernel. Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data. I _really_ don't like what you are doing with these symlinks. For one thing, you have no exclusion between reading the list entries and modifying them. That's easy enough to fix. I'll do it. For another... WTF is filesystem making assumptions about the locations where the things are mounted? I assume by this that you're objecting to the initialization of /smack/tmp to point to /moldy/label. Over the years I've seen a number of cases where failure to set up /tmp result in unhappy consequences. If /tmp is anything other than a real directory on the root filesystem it is important that special care be taken for the case where things don't get set up right for some reason. By including a specific, if perhaps arbitrary, default it becomes easier to create a configuration that survives the unexpected. Hell, even if you override your tmp symlink, Which is something that I expect virtually everyone to do. what happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? Because you throw simple out the window when you require userland assistance to perform this function. No problems with absolute paths, can be used in chroot jails with whatever layouts, ditto for namespaces, etc. and both symlink and directory get created at the same time (by one name). Hell, if you keep a reference to dentry of directory in the data associated with symlink, you can simply switch nd-dentry to that, drop the old one and grab the reference to page containing label and return it via nd_set_link(). No need to play with allocations, strcat, yadda, yadda. readlink() can stuff the -d_name of the same dentry plus / plus label directly into user buffer; again, no allocations needed and works fine anywhere. I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: what happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. Of course you can mount it more than once. Just bind the sucker and you are done. I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 07:17:35PM +0100, Alan Cox wrote: Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? Presumably his context can change within a login session? If not, it's indeed simply worthless, absolute paths or not. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote: what happens if we want it in two chroot jails with different layouts? As you can only have /smack mounted once, this isn't an issue, but it does present an interesting use case that brings the one mount limitation into question. I'll add addressing this to the short term todo list. Of course you can mount it more than once. Just bind the sucker and you are done. I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp - /smack/tmp - /moldy/label has every other scheme I've seen throughly beaten. I'm having some trouble seeing how the 60 lines of code in smackfs dealing with symlinks would be improved by your suggestions. I certainly don't see how requiring userland intervention would do anything but make it bigger and less reliable. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Who said anything about mounting under /moldy? I never did. Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. Is the objection that there is a default value coded in? Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox [EMAIL PROTECTED] wrote: Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. What I don't understand here is why we need the hacks when we already support sufficient mount magic to give each login session its own private /tmp ? An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. I don't see what is such a problem here. For your mobile example you'd give the application download side its own /tmp via mount. Its actually better this is done in user space as its more flexible that way and can be tuned arbitarily to meet interesting or bizarre real world cases. Alan - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp - /smack/tmp - /moldy/label has every other scheme I've seen throughly beaten. And your point is? If you don't use it, you get exact same complexity in both setups. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Who said anything about mounting under /moldy? I never did. Sigh... So put the binding into fstab and be done with that. Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. Is the objection that there is a default value coded in? Right now the main objection is about your lack of ability to read. Which part of it can be mounted in different chroots/namespaces, therefore having absolute paths doesn't work is too hard to understand? No, it's not about having a default. It's about keeping an absolute pathname in virtual fs, having all instances autosoddingmatically sharing it _and_ having change attempt in any instance automatically affect all of them. If you have that kind of sharing, don't pretend that your mechanism really allows absolute pathnames. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Alan Cox [EMAIL PROTECTED] wrote: An embedded system that does not have user logins but that does have applications that require separation, perhaps a moble communication device with application download capability, is just one example where the smack symlink implementation provides the required function without requiring application support. I don't see what is such a problem here. For your mobile example you'd give the application download side its own /tmp via mount. Its actually better this is done in user space as its more flexible that way and can be tuned arbitarily to meet interesting or bizarre real world cases. I admit to being impressed by the wide variety of mount options currently available. In many cases this will be the best approach. /tmp is a typical use for a smack symlink, but not the only one. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote: Because you throw simple out the window when you require userland assistance to perform this function. Any more than having /tmp replaced with a symlink? Yes. By the way, there's nothing that really requires that you use a /smack symlink if you don't want to. /tmp can still be a real directory, a mount point, a symlink to /var/tmp, or whatever else you want it to be if that suits your needs better. For the simplest scenarios /tmp - /smack/tmp - /moldy/label has every other scheme I've seen throughly beaten. And your point is? If you don't use it, you get exact same complexity in both setups. Thank you for your patience. Let me see if I can get my point across. The intended Smack scenario: 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp /tmp All processes are now redirected into the appropriate place regardless of how they come into being. It doesn't matter if the session starts from busybox, login, sshd, xdm, crontab, or out of an init script. _What_ userland intervention? Mounting stuff under /smack/tmp and not under your /moldy? Who said anything about mounting under /moldy? I never did. Sigh... So put the binding into fstab and be done with that. Are you suggesting that /smack/tmp.link below is a mount point, and that appropriate directories get mounted there? 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 2c. mount --bind /moldy/label /smack/tmp.link/label 3. ln -s /smack/tmp.link /tmp Having /tmp replaced with symlink to /smack/tmp.link instead of replacing it with a symlink to /smack/tmp? Absolute paths in that kind of thing are _wrong_. You know where the things are on your fs. You don't know if anything else will be visible, let alone whether it will be at the same place in all chroots or namespaces. And no, you _can't_ make sure that fs is visible only in one place. No fs can or has any business even trying. Is the objection that there is a default value coded in? Right now the main objection is about your lack of ability to read. Now you sound like my daughter. :-) Which part of it can be mounted in different chroots/namespaces, therefore having absolute paths doesn't work is too hard to understand? It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. No, it's not about having a default. Nuts. That would have made addressing your concern easy. It's about keeping an absolute pathname in virtual fs, It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. having all instances autosoddingmatically sharing it _and_ having change attempt in any instance automatically affect all of them. If you have that kind of sharing, don't pretend that your mechanism really allows absolute pathnames. Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? I think it would, but as you pointed out earlier, my lack of ability to read may be clouding my understanding. Thank you. Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp /tmp 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp.link /tmp 4. mount --bind /moldy /smack/tmp or add /moldy /smack/tmp none bind,rw 0 2 to /etc/fstab (same effect as (4)) Compare with your variant; the difference is in one argument of ln(1) and one additional line in rc script or /etc/fstab. Sorry, but I don't buy the extra setup complexity argument at all. It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. It's not about symlink pointing to /smack/something; it's about the place where /smack/something itself points to. And _that_ can bloody well be different in different chroots. Look, if you allow to change where it goes, you certainly allow different prefices on different boxen; moreover, admin can change it freely according to his layout on given box. OTOH, you _can't_ have it different in different chroots and changing it in one will affect all of them. See why that's a problem? It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. Fixed-contents symlink (with or without variable tail - it's irrelevant here) is a bloody wrong tool for that kind of fs for the reasons described above. And if you go for prefix should point to location on the same fs you can trivially configure the rest in userland (one line describing a binding), leaving the kernel-side stuff with something like userland can ask for a pair of symlink and directory, having symlink resolve to directory + label instead of your userland can ask for a symlink resolving to prefix + label. And _that_ is chroot-neutral - you don't need to do any extra work... Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? ... like that one. Leave it to normal userland mechanisms; it's a matter of a single line in whatever script you are using to set chroot up and it involves _way_ fewer caveats. That said, Alan's point still stands - if you don't get processes changing context back and forth, you don't need anything at all - we already have all we need for that kind of setups (and no, selinux is not involved ;-). - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote: 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp /tmp 1. Create /moldy at _ 2. For each label you care about 2a. Create /moldy/label 2b. Set the label of /moldy/label to label 3. ln -s /smack/tmp.link /tmp 4. mount --bind /moldy /smack/tmp or add /moldy /smack/tmp none bind,rw 0 2 to /etc/fstab (same effect as (4)) Compare with your variant; the difference is in one argument of ln(1) and one additional line in rc script or /etc/fstab. Sorry, but I don't buy the extra setup complexity argument at all. What I'm confused about is how that results in a process labeled foo getting a different /tmp from a process labeled bar. I guess I'll have to review your first post. It's the content of a symlink, and that can be just about anything and is not required to point to anything, which is one reason why I made that choice. If you don't have a /tmp, or can't write to the /tmp that exists, or have a /tmp that's a dangling symlink under any circumstances you may have an issue. That's true regardless of the presence or absense of /smack. All of the traditional mechanisms for dealing with /tmp in a chrooted or namespaced environment remain. It's not about symlink pointing to /smack/something; it's about the place where /smack/something itself points to. And _that_ can bloody well be different in different chroots. Which is completely OK with me. Look, if you allow to change where it goes, you certainly allow different prefices on different boxen; moreover, admin can change it freely according to his layout on given box. OTOH, you _can't_ have it different in different chroots and changing it in one will affect all of them. See why that's a problem? Yes, I can see that could be an unexpected behavior. It's in a symlink on the filesystem, and it doesn't have to be an absolute pathname, although since it's a symlink and the semantics for a symlink allow that be be absolute, relative, or dangling I don't see any reason to restrict it from being absolute. Fixed-contents symlink (with or without variable tail - it's irrelevant here) is a bloody wrong tool for that kind of fs for the reasons described above. I do not understand where the concept of Fixed-contents symlink comes from. Yes, tmp is initialized to /moldy/, but that can be changed by writing to /smack/links. Please help me understand the what you mean by fixed-contents symlinks. And if you go for prefix should point to location on the same fs you can trivially configure the rest in userland (one line describing a binding), leaving the kernel-side stuff with something like userland can ask for a pair of symlink and directory, having symlink resolve to directory + label instead of your userland can ask for a symlink resolving to prefix + label. And _that_ is chroot-neutral - you don't need to do any extra work... Could allowing multiple distinct mounts and symlink assignments of /smackfs address those issues? ... like that one. Leave it to normal userland mechanisms; it's a matter of a single line in whatever script you are using to set chroot up and it involves _way_ fewer caveats. That said, Alan's point still stands - if you don't get processes changing context back and forth, you don't need anything at all - we already have all we need for that kind of setups (and no, selinux is not involved ;-). Casey Schaufler [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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: > > From: Casey Schaufler <[EMAIL PROTECTED]> > > Smack is the Simplified Mandatory Access Control Kernel. > > Smack implements mandatory access control (MAC) using labels > attached to tasks and data containers, including files, SVIPC, > and other tasks. Smack is a kernel based scheme that requires > an absolute minimum of application support and a very small > amount of configuration data. I _really_ don't like what you are doing with these symlinks. For one thing, you have no exclusion between reading the list entries and modifying them. For another... WTF is filesystem making assumptions about the locations where the things are mounted? Hell, even if you override your tmp symlink, what happens if we want it in two chroot jails with different layouts? I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/ and have userland bind or mount whatever you bloody like on /smack/tmp? No problems with absolute paths, can be used in chroot jails with whatever layouts, ditto for namespaces, etc. and both symlink and directory get created at the same time (by one name). Hell, if you keep a reference to dentry of directory in the data associated with symlink, you can simply switch nd->dentry to that, drop the old one and grab the reference to page containing label and return it via nd_set_link(). No need to play with allocations, strcat, yadda, yadda. readlink() can stuff the ->d_name of the same dentry plus / plus label directly into user buffer; again, no allocations needed and works fine anywhere. - 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: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote: From: Casey Schaufler [EMAIL PROTECTED] Smack is the Simplified Mandatory Access Control Kernel. Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data. I _really_ don't like what you are doing with these symlinks. For one thing, you have no exclusion between reading the list entries and modifying them. For another... WTF is filesystem making assumptions about the locations where the things are mounted? Hell, even if you override your tmp symlink, what happens if we want it in two chroot jails with different layouts? I really don't get it; why not simply have something like /smack/tmp.link resolve to tmp/label and have userland bind or mount whatever you bloody like on /smack/tmp? No problems with absolute paths, can be used in chroot jails with whatever layouts, ditto for namespaces, etc. and both symlink and directory get created at the same time (by one name). Hell, if you keep a reference to dentry of directory in the data associated with symlink, you can simply switch nd-dentry to that, drop the old one and grab the reference to page containing label and return it via nd_set_link(). No need to play with allocations, strcat, yadda, yadda. readlink() can stuff the -d_name of the same dentry plus / plus label directly into user buffer; again, no allocations needed and works fine anywhere. - 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/
