Re: AppArmor Security Goal
On Sat, November 10, 2007 22:04, Andi Kleen wrote: > Crispin Cowan <[EMAIL PROTECTED]> writes: > > The document should be a good base for a merge. > >> * A confined process can operate on a file descriptor passed to it >> by an unconfined process, even if it manipulates a file not in the >> confined process's profile. To block this attack, confine the >> process that passed the file descriptor. > > That is the only thing that tripped me up a bit while reading the > document. > Can you expand a bit on the reasons why the fd is not rechecked in > the context of the target process? Best do it in a new version of the > document. You must try to considder what could actualy be a valid reason for re-checking here, and what it could accomplish. If the unconfined process A is in 'full communication' with the unconfined process B and wants B to have the 'authority' to do anything with file C that it can do, there is no way of stopping A from doing so. Stopping A from communicating its 'permission' to do so would thus be useless for that purpose. The only way of stopping A from comminucating its authority with A is stopping A from communicating with B period. Ones you accept that trying to stop delegation of authority by stopping delegation of permission is useless, you can see that ther are major advantages with respect to allowing a process with least authority, if you actualy 'accomodate' the delegation of authority. This is the main reason why I actualy feel strongly that a more extended set of delegation possibilities (both of ambient and object capabilities) would be complementary to AppArmor, in that it would allow the convenience of defining the lower bound of priviledges to a delegation based scheme, while allowing at the same time a 'thin profile' for OC aware programs. Rob J Meijer - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser(2)
Hi! > > A Smack Rule in an "egrep" format is: > > > > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n" Perhaps you should make it space, not 'space or tab', and only allow lowercase permissions? That way, parser will be slightly simpler, and you'll still have a chance to use 'R' as 'slightly different r'. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser(2)
Hi Pavel, On Nov 11, 2007 2:44 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > A Smack Rule in an "egrep" format is: > > > > > > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n" > > Perhaps you should make it space, not 'space or tab', and only allow > lowercase permissions? That way, parser will be slightly simpler, and > you'll still have a chance to use 'R' as 'slightly different r'. > Thanks for your care about this. It seems not a lot of people have noticed, but to stop any objections not related to the core smack code, Casey decided to let the parsing be done in a user-space utility that sends the rules to the kernel in a predefined strict format. You can find how the whole story in the smackv11 announcement here: http://article.gmane.org/gmane.linux.kernel.lsm/4463 Regards, -- Ahmed S. Darwish Homepage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v6 08/13] SELinux: Add new peer permissions to the Flask definitions
On Fri, 9 Nov 2007, Paul Moore wrote: > Add additional Flask definitions to support the new "peer" object class. Should this be dependent on dynamic class/permission support? Or, will these checks only be invoked if labled networking is configured? -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v6 09/13] SELinux: Better integration between peer labeling subsystems
On Fri, 9 Nov 2007, Paul Moore wrote: > + /* Between selinux_compat_net and selinux_policycap_netpeer this is > + * starting to get a bit messy - we need to setup a timetable for > + * deprecating some of this old/obsolete functionality so we can > + * reclaim some level of sanity in this function. */ I don't think we can do anything which could potentially break userspace now. So, this one really needs to be right :-) -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 64 bit capabilities
Andrew Morgan,
>> I'll post the patch of setfcaps/getfcap for his tree.
>> I believe it is better way to maintain.
>>
>> Thanks,
The following patch to libcap enables to display file capabilities
recursively on the enumerated directories when -r is specified.
In addition, some other features are ported from my getfcap.
When an entry contains no file-capabilities, displaying it will be
skipped without returning an error. However, -v option enables to
display those filenames with no capabilities.
-h options displays short usage message.
Please consider to apply it on your tree.
EXAMPLE:
[EMAIL PROTECTED] libcap]$ ./progs/getcap -r /tmp
/tmp/ping = cap_net_raw+ep
[EMAIL PROTECTED] libcap]$
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
doc/getcap.8 | 14 +++-
progs/getcap.c | 101 ++-
2 files changed, 96 insertions(+), 19 deletions(-)
diff --git a/doc/getcap.8 b/doc/getcap.8
index a0e2c41..9ed5c33 100644
--- a/doc/getcap.8
+++ b/doc/getcap.8
@@ -2,14 +2,24 @@
.\" $Id: getcap.8,v 1.1.1.1 1999/04/17 22:16:31 morgan Exp $
.\" written by Andrew Main <[EMAIL PROTECTED]>
.\"
-.TH GETCAP 8 "26th April 1997"
+.TH GETCAP 8 "12 Nov 2007"
.SH NAME
getcap \- examine file capabilities
.SH SYNOPSIS
-\fBgetcap\fP \fIfilename\fP [ ... ]
+\fBgetcap\fP [-v] [-r] [-h] \fIfilename\fP [ ... ]
.SH DESCRIPTION
.B getcap
displays the name and capabilities of each specified
+.SH OPTIONS
+.TP 4
+.B -r
+enables recursive search.
+.TP 4
+.B -v
+enables to display all searched entries, even if it has no file-capabilities.
+.TP 4
+.B -h
+prints quick usage.
.IR filename .
One file per line.
.SH "SEE ALSO"
diff --git a/progs/getcap.c b/progs/getcap.c
index 1fbf5d2..a1daa30 100644
--- a/progs/getcap.c
+++ b/progs/getcap.c
@@ -8,45 +8,112 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
+static int verbose = 0;
+static int recursive = 0;
+
static void usage(void)
{
fprintf(stderr,
- "usage: getcap [ ...]\n"
+ "usage: getcap [-v] [-r] [-h] [ ...]\n"
"\n"
"\tdisplays the capabilities on the queried file(s).\n"
);
exit(1);
}
-int main(int argc, char **argv)
+static void do_recursive(const char *fname);
+
+static void do_getcap(const char *fname)
{
-char *result=NULL;
+cap_t cap_d;
+char *result;
-if (argc < 2) {
- usage();
+cap_d = cap_get_file(fname);
+if (cap_d == NULL) {
+ if (errno != ENODATA) {
+ fprintf(stderr, "Failed to get capabilities of file `%s' (%s)\n",
+ fname, strerror(errno));
+ } else if (verbose) {
+ printf("%s\n", fname);
+ }
+ goto out;
}
-for ( ++argv; --argc > 0; ++argv ) {
- ssize_t length;
- cap_t cap_d;
+result = cap_to_text(cap_d, NULL);
+if (!result) {
+ fprintf(stderr,
+ "Failed to get capabilities of human readable format at `%s'
(%s)\n",
+ fname, strerror(errno));
+ cap_free(cap_d);
+ return;
+}
+printf("%s %s\n", fname, result);
+cap_free(cap_d);
+cap_free(result);
- cap_d = cap_get_file(argv[0]);
+ out:
+if (recursive) {
+ struct stat stbuf;
- if (cap_d == NULL) {
- fprintf(stderr, "Failed to get capabilities for file `%s' (%s)\n",
- argv[0], strerror(errno));
- continue;
+ if (stat(fname, &stbuf)) {
+ fprintf(stderr, "Failed to get attribute of file `%s' (%s)\n",
+ fname, strerror(errno));
+ } else if (S_ISDIR(stbuf.st_mode)) {
+ do_recursive(fname);
}
+}
+}
+
+static void do_recursive(const char *fname)
+{
+DIR *dirp;
+struct dirent *dent;
+char buffer[PATH_MAX];
- result = cap_to_text(cap_d, &length);
+dirp = opendir(fname);
+if (dirp == NULL) {
+ fprintf(stderr, "Failed to open directory `%s' (%s)\n",
+ fname, strerror(errno));
+ return;
+}
- printf("%s: %s\n", *argv, result);
+while ((dent = readdir(dirp)) != NULL) {
+ if (!strcmp(dent->d_name, ".") || !strcmp(dent->d_name, ".."))
+ continue;
+ snprintf(buffer, PATH_MAX, "%s/%s", fname, dent->d_name);
+ do_getcap(buffer);
+}
+closedir(dirp);
+}
- cap_free(result);
- cap_free(cap_d);
+int main(int argc, char **argv)
+{
+int i, c;
+
+while ((c = getopt(argc, argv, "rvh")) > 0) {
+ switch(c) {
+ case 'r':
+ recursive = 1;
+ break;
+ case 'v':
+ verbose = 1;
+ break;
+ default:
+ usage();
+ }
}
+if (!argv[optind])
+ usage();
+
+for (i=optind; argv[i] != NULL; i++)
+ do_getcap(argv[i]);
+
return 0;
}
-
To unsubscribe from this list: send the li
