Howdy. I really have nothing at all to do with Fedora, don't use it. Never even seen it. However, you seem to be the only group interested in SELinux for the masses, so I'm going to lay out an idea I've had.
SELinux has a place on the desktop.
Currently, a large piece is missing from the desktop security landscape. User's can receive, by email or IM, executable files. These can be in the form of actual real binaries, pseudo-binaries (flash), or script languages (javascript, html, etc). Up to now the current attitude has been "don't open files you don't trust, don't go to websites you don't trust, don't run scripts you don't trust". This "rule" ignores one common principle. USERS DONT CARE! It doesn't matter that they SHOULDN"T open an executable their friend or co-worker sends them, they will anyways. Is this so bad? I don't think so.
So here's where SELinux comes in. SELinux allows the system to place restrictions on executable programs beyond that offered by the user identity itself. It allows you to audit, and deny syscall execution, which is every programs interface to the world.
So why can't one program place SELinux policy's on other software? Why can't a desktop interface listen for faults in SELinux, change those policy's based on the user's actions or requests, and let the program continue, at runtime?
Consider the following example:
Bob receives an executable from his co-worker Joe. Bob opens it from his email. His email client sets up a policy restricting all access to everything, except maybe /tmp, and the obvious, the program runs. Oh no! It's a virus! The program attempts to establish a connection to Bob's address book (exposed by evolution data server). SELinux detects the programs attempts to open a socket that it was not allowed to do. The program blocks on the syscall. SELinux is configured to continue blocking the program until told otherwise. SELinux locates a D-BUS daemon for Bob and notifies it about the security event. Running as Bob is sec-policy-daemon which is listening to D-BUS for fault notifications. This daemon reads the information Bob's email client attached to the process. The information reads as follows:
1) don't allow the program to do anything except read/write to /tmp 2) do allow the program to open outgoing ports after notifying the user
The daemon realizes that the action isn't allowed, but that it could be allowed if the user consents to it, so the daemon pops up on the user's desktop a nice dialog box, "The application Blah has attempted to access the file /tmp/contact-socket (or whatever). Do you want to allow this action?" Most likely t his dialog would ask for the user's password again. Upon receiving a "Yes", SELinux would be instructed to allow the program to access the socket. If the user presses Yes, the process ceases being blocked, and goes on. In the case of No, the process will probably die. ;0
Of course this policy would be configurable. In some offices admins would probably not want the user to even have the option to open outgoing ports from downloaded software, they just don't wnat to take the risk. In some home circumstances, it might be a little bit looser. It's up to you.
What this does is let users do what they will do anyways: run the program. You won't stop them, I won't stop them, and we probably shouldn't. We should make it so they CAN without risk to their systems.
Do enjoy. I hope you guys do something with this. It's what we need.
Jerry Haltom wasabi@larvalstage.net
On Tue, Oct 12, 2004 at 08:14:16PM -0500, Jerry Haltom wrote:
The daemon realizes that the action isn't allowed, but that it could be allowed if the user consents to it, so the daemon pops up on the user's desktop a nice dialog box, "The application Blah has attempted to access the file /tmp/contact-socket (or whatever). Do you want to allow this action?" Most likely t his dialog would ask for the user's password again. Upon receiving a "Yes", SELinux would be instructed to allow the program to access the socket. If the user presses Yes, the process ceases being blocked, and goes on. In the case of No, the process will probably die. ;0
[...]
What this does is let users do what they will do anyways: run the program. You won't stop them, I won't stop them, and we probably shouldn't. We should make it so they CAN without risk to their systems.
What's to stop a user from always clicking "Yes"? What makes you think that those same users who download/open attachments that are executables without thinking/understanding the consequences will be any smarter when they are asked whether or not to allow a program to perform some obscure system internal function that they have even less of a chance understanding?
I don't think it is advantageous to give the user choices they don't have any chance of understanding. The current Fedora strict SELinux policy already restricts some network-facing desktop applications, such as Mozilla.
On Tue, 2004-10-12 at 20:14 -0500, Jerry Haltom wrote:
So here's where SELinux comes in. SELinux allows the system to place restrictions on executable programs beyond that offered by the user identity itself. It allows you to audit, and deny syscall execution,
Not precisely. System calls aren't directly restricted; there are simply hooks placed at security-relevant code paths in the kernel. Not all system calls are restricted, and not all permissions are obviously mappable to one particular system call. Also, you can have userspace policy enforcers like D-BUS that aren't mappable to kernel syscalls at all.
So why can't one program place SELinux policy's on other software?
SELinux provides mandatory access control, so the policy is generally controlled centrally by a security administrator. However, it is possible right now for the administrator to allow some discretionary user control over labeling. That's what the Apache policy does.
Why can't a desktop interface listen for faults in SELinux, change those policy's based on the user's actions or requests, and let the program continue, at runtime?
The problem with this that I see is that it's very difficult to present this to the user in a meaningful way. Most users will simply have no idea what's going on:
- don't allow the program to do anything except read/write to /tmp
- do allow the program to open outgoing ports after notifying the user
A lot of end users aren't going to know what /tmp, ports, or evolution- data-server are. Or even if they do, it's difficult to say whether the program is actually doing something bad or not.
One major problem is that right now, without Security-Enhanced X, as soon as you grant an untrusted application access to your X connection you are screwed. So it's basically impossible to usefully define a "user_untrusted_t" domain that downloaded programs could run in; they wouldn't be able to do anything besides use CPU. I guess you could pop them up in a terminal with a suitable program doing filtering with a pty, but I don't see many people emailing exciting tty-based applications to each other...
Jerry Haltom wasabi-at-larvalstage.net |fedora| wrote:
USERS DONT CARE! It doesn't matter that they SHOULDN"T open an executable their friend or co-worker sends them, they will anyways. Is this so bad?
In a word, yes. By your own definition they are not security experts, so they don't know what they are supposed to do and they will gladly click on any button that they think will show them what they think they are supposed to see happen. If the "yes" button does not work then they will download it again and try the "no" button instead. Trial and error is not what SELinux is about.
The daemon realizes that the action isn't allowed, but that it could be allowed if the user consents to it,
My congradulations to this user, as they are now a certified security officer (lol), so they *must* know which is the best button to click on. Will that be door number one, ... or door number two? Or you can trade it all for ... a ..BRAND.. NEW.. JOB!! (ding) (ding) (ding). Oh, sorry, got carried away for a sec. ;)
Even pavlov's dog understood the suggestive power of repetition, so if they clicked "yes" three times in a row last week there is about a 90% probablility they will click the "yes" button today without even reading the text of the yes/no box. If your going to give them a choice then you are going to have to train them how to be smart about it, or create a *corporate policy*, but then you already said they will just ignore that.
In the case of No, the process will probably die. ;0
I also think the desktop should have some smarts built in, but my vote would be to have the "desktop" send a sigterm to the errant process and put up a "don't do that!" modal dialog box for which the user has to acknowlege in order to continue. Of course I can't ignore the possibility that a user might actually *need* to run a binary given to them, for which I would propose that it be 1) "signed" (just warm fuzzy feeling, but not a true protection methodology) and 2) run in a *real* partitioned Virtual Machine, sandbox a la VMWare/Plex86/etc. or as near as one can get to that, such as a chrooted sandbox with a very restrictive SE policy.
This does bring to mind a burning question I have always had reguarding some applications such as Java where the binary itself is too open ended and where as the compiled class files, script file, or data dictate what the runtime will do. I assume that many desktop environments (take your pick) will have some form of builtin scripting support. How does SELinux deal with these VM's? Is there any good docs online that discuss the problems and current solutions that these present? Do they get their security context from the script or data streams?
Thanks!
On Wed, 2004-10-13 at 11:20, Steve Coleman wrote:
This does bring to mind a burning question I have always had reguarding some applications such as Java where the binary itself is too open ended and where as the compiled class files, script file, or data dictate what the runtime will do. I assume that many desktop environments (take your pick) will have some form of builtin scripting support. How does SELinux deal with these VM's? Is there any good docs online that discuss the problems and current solutions that these present? Do they get their security context from the script or data streams?
From the program/script. Transitions can occur on scripts (if they are
exec'd), but the caller domain needs to be trusted with respect to the new domain (e.g. shedding permissions) in that case due to the lack of safety in script execution.
Note that SELinux provides the necessary API to support userland policy enforcers, so a userspace VMM can be modified to use that API to obtain policy decisions to be applied to its internal abstractions which are not directly visible to the OS itself. dbus and X (but unfortunately not the X in Fedora yet) have been modified to use that API to enforce policy over their abstractions. This allows for layered security, with the OS providing process-level confinement and the higher level object managers refining that control.
On Wed, 2004-10-13 at 13:59 -0400, Stephen Smalley wrote:
From the program/script. Transitions can occur on scripts (if they are
exec'd), but the caller domain needs to be trusted with respect to the new domain (e.g. shedding permissions) in that case due to the lack of safety in script execution.
The major threat here is environment variables, right? I wonder what all would break if we by changed e.g. bash and python to by default clean the environment before executing the script if it was executed from a domain transition (they could check in the same way glibc does, right?).
Colin Walters walters-at-redhat.com |fedora| wrote:
The major threat here is environment variables, right?
That one is a minor issue in my book, but certainly worth trying to enforce in some way.
I wonder what all would break if we by changed e.g. bash and python to by default clean the environment before executing the script if it was executed from a domain transition
Could be a lot. If you sanitize classpath or PERL5LIB a lot could break, but it you don't you might not be running what you think you are, which leads back to what I was inquiring about.
So just to clarify, whats the difference between a user running a script file that does exec "java ./MyClass.class" and a stack overrun causing a browser with a smashed stack to save a MyBackdoor.class to the local file system and execing "java ./MyBackdoor.class -irc blackhathosting.org" ?
In both cases its the same user, and in both cases its the same java VM binary. The java binary is likely the only process that knows enought to enforce anything here based on when, what, and where things are run by the user. The browser may try to limit what permissions are passed to the exec call but with a smashed stack overrun can you trust it to? Not me, at least not yet. This looks to me like the java VM needs to be hacked with the SELinux API in order to have any confidence in it, but in some ways that duplicates the java security managers role in life. Perhaps we just need a specialized Java security manager, perhaps much more. Dunno. But its a common issue with desktop actions and shells, as well as Perl, Python, Ruby, just pick your poison...
I guess what I was looking for was a phylosophy for how to handle this nebulous issue. The more likely answer is each has its own issues and must be dealt with seperatly in its own special way and must be changed to deal with SE. I am hoping for a better option as there is much in SE I don't know yet and I do want to understand it in great detail some way down the road.
Thanks.
On Thu, 2004-10-14 at 13:56, Steve Coleman wrote:
Colin Walters walters-at-redhat.com |fedora| wrote:
The major threat here is environment variables, right?
Hmm...didn't get Colin's original message, but I saw this reply. Anyway, if the question is about domain transitions on scripts, then there is a fundamental race condition on script execution. Think: kernel looks up script file and reads header, kernel invokes interpreter with script file path as argument, interpreter looks up script file. Caller can run arbitrary code in the new domain.
On Thu, 2004-10-14 at 14:27 -0400, Stephen Smalley wrote:
On Thu, 2004-10-14 at 13:56, Steve Coleman wrote:
Colin Walters walters-at-redhat.com |fedora| wrote:
The major threat here is environment variables, right?
Hmm...didn't get Colin's original message, but I saw this reply. Anyway, if the question is about domain transitions on scripts, then there is a fundamental race condition on script execution. Think: kernel looks up script file and reads header, kernel invokes interpreter with script file path as argument, interpreter looks up script file. Caller can run arbitrary code in the new domain.
Well, this is only a threat in the case where the caller can do an unlink in the directory that the script is in, correct? I can see that's a fundamental problem, but personally I'm more interested in trying to for example give someone the ability to run /etc/init.d/* in a secure manner. Say we define a type like 'daemon_admin_t' that has permissions to transition to initrc_t; perhaps we'd need to label certain files in /etc/init.d/ instead of allowing general access to initrc_t. Right now though if you tried to do that a malicious attacker could set many environment variables like PATH or IFS which shell scripts would pick up. Cleaning the environment would close that hole.
On Thu, 2004-10-14 at 14:51, Colin Walters wrote:
Well, this is only a threat in the case where the caller can do an unlink in the directory that the script is in, correct?
No, because the kernel just passes through the path as provided; it doesn't canonicalize it. So you can use a symlink or hard link in your home directory to the real script, then rewrite that path to refer to something else.
Right now though if you tried to do that a malicious attacker could set many environment variables like PATH or IFS which shell scripts would pick up. Cleaning the environment would close that hole.
SELinux does enable glibc secure mode upon a domain transition, and glibc does sanitize certain environment variables in that case. So you could possibly add further variables to the list used by glibc to help protect scripts. But that won't resolve the race.
I think that Solaris addressed the race by having the kernel open the script file and provide the descriptor to the interpreter, much as Linux already does for the ELF interpreter. Problem with that solution is that userspace expects a path, not a fd, so I think Solaris passes /dev/fd/n as the path. That would seem to almost work, except that /dev/fd/n -> /proc/self/fd/n on Linux becomes inaccessible upon setuid/setgid execution to avoid an information leak.
On Thu, 2004-10-14 at 13:56, Steve Coleman wrote:
So just to clarify, whats the difference between a user running a script file that does exec "java ./MyClass.class" and a stack overrun causing a browser with a smashed stack to save a MyBackdoor.class to the local file system and execing "java ./MyBackdoor.class -irc blackhathosting.org" ?
Calling context. User is initially in a given domain (e.g. user_t), runs script file that may or may not transition depending on policy. Browser runs in a different domain (e.g. user_mozilla_t) that has a subset of user_t's permissions. Further, files writable by browser domain are not executable by user directly without explicit relabel by user. (Note: I don't know if that is still true in the present Fedora policy, but certainly possible to configure it that way).
In both cases its the same user, and in both cases its the same java VM binary.
SELinux can capture the entire call chain (via execve, not function calls here) if desired, e.g. distinguishing here on the browser, although you typically only encode new domains where you cross a trust boundary.
The java binary is likely the only process that knows enought to enforce anything here based on when, what, and where things are run by the user.
SELinux can enforce a coarse-grained policy over the maximum access granted to the process. But I agree that the VMM ultimately needs some awareness of security to refine that policy to deal with the finer-grained internal abstractions it manages. Nonetheless, you don't want to rely entirely on the VMM's enforcement, as it may be subverted itself.
Hi all,
I dont know if this makes any sense but can any one tell me if we can set up a policy where a user_r has more previleges than the staff_r (not the sys admin). thanx in advance..
Ram
On Wed, 13 Oct 2004 13:59:02 -0400, Stephen Smalley sds@epoch.ncsc.mil wrote:
On Wed, 2004-10-13 at 11:20, Steve Coleman wrote:
This does bring to mind a burning question I have always had reguarding some applications such as Java where the binary itself is too open ended and where as the compiled class files, script file, or data dictate what the runtime will do. I assume that many desktop environments (take your pick) will have some form of builtin scripting support. How does SELinux deal with these VM's? Is there any good docs online that discuss the problems and current solutions that these present? Do they get their security context from the script or data streams?
From the program/script. Transitions can occur on scripts (if they are
exec'd), but the caller domain needs to be trusted with respect to the new domain (e.g. shedding permissions) in that case due to the lack of safety in script execution.
Note that SELinux provides the necessary API to support userland policy enforcers, so a userspace VMM can be modified to use that API to obtain policy decisions to be applied to its internal abstractions which are not directly visible to the OS itself. dbus and X (but unfortunately not the X in Fedora yet) have been modified to use that API to enforce policy over their abstractions. This allows for layered security, with the OS providing process-level confinement and the higher level object managers refining that control.
-- Stephen Smalley sds@epoch.ncsc.mil National Security Agency
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Wed, 2004-10-13 at 14:57, Kodungallur Varma wrote:
I dont know if this makes any sense but can any one tell me ifwe can set up a policy where a user_r has more previleges than the staff_r (not the sys admin). thanx in advance..
Why? The current policy is set up so that staff_r is more privileged than user_r (if the user_canbe_sysadm tunable is disabled); otherwise, user_r and staff_r are essentially equivalent. I'd suggest disabling user_canbe_sysadm and optionally adding further permissions to staff_r, not the other way around.
On Wed, 2004-10-13 at 14:57 -0400, Kodungallur Varma wrote:
Hi all,
I dont know if this makes any sense but can any one tell me ifwe can set up a policy where a user_r has more previleges than the staff_r (not the sys admin). thanx in advance..
You can grant any additional privileges to user_t that you want; just add them in say domains/misc/local.te.
On Wed, 13 Oct 2004 13:59:02 EDT, Stephen Smalley said:
not directly visible to the OS itself. dbus and X (but unfortunately not the X in Fedora yet) have been modified to use that API to enforce policy over their abstractions.
Where might one find a patch for this that has a snowball's chance of working on an xorg X source tree?
On Thu, 2004-10-14 at 11:15, Valdis.Kletnieks@vt.edu wrote:
On Wed, 13 Oct 2004 13:59:02 EDT, Stephen Smalley said:
not directly visible to the OS itself. dbus and X (but unfortunately not the X in Fedora yet) have been modified to use that API to enforce policy over their abstractions.
Where might one find a patch for this that has a snowball's chance of working on an xorg X source tree?
See http://marc.theaimsgroup.com/?l=selinux&m=108483628322478&w=2. It is available in a branch of the xorg CVS tree. But unfortunately, the developer of security-enhanced X has moved on to another office and it hasn't been maintained since July, AFAIK.
-----Original Message----- From: fedora-selinux-list-bounces@redhat.com [mailto:fedora-selinux-list- bounces@redhat.com] On Behalf Of Stephen Smalley Sent: Monday, October 18, 2004 8:34 AM To: Fedora SELinux support list for users & developers. Subject: Re: SELinux and the Desktop
On Thu, 2004-10-14 at 11:15, Valdis.Kletnieks@vt.edu wrote:
On Wed, 13 Oct 2004 13:59:02 EDT, Stephen Smalley said:
not directly visible to the OS itself. dbus and X (but unfortunately not the X in Fedora yet) have been modified to use that API to enforce policy over their abstractions.
Where might one find a patch for this that has a snowball's chance of
working
on an xorg X source tree?
See http://marc.theaimsgroup.com/?l=selinux&m=108483628322478&w=2. It is available in a branch of the xorg CVS tree. But unfortunately, the developer of security-enhanced X has moved on to another office and it hasn't been maintained since July, AFAIK.
You can also view the source here:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/?root=xorg&only_with_tag=X... SELINUX
Karl
Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134
-- Stephen Smalley sds@epoch.ncsc.mil National Security Agency
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
Chuck Anderson -
Colin Walters -
Jerry Haltom -
Karl MacMillan -
Kodungallur Varma -
Stephen Smalley -
Steve Coleman -
Valdis.Kletnieks＠vt.edu