Re: Configuring GDM to limit user actions
On Sunday 08 February 2004 15:34, David Sapir wrote: Hi, I would like to know how to configure Gnome on RH9 for a specific user: * control the menus from the start menu (which item will appear in the menues) * control which application a user can activate (run) * require a root password (or a previledged user password) for certain applications I did not find a suitable answer for that on the web. Maybe anyone has a lead for me to follow? If you think I cannot accomplish that in Gnome environment, please tell me which env and how to do it (or where to look for the answer), because I don't know any other GUI environments. Check out KDE's kiosk mode. If you're inclined to digging in, it will provide important clues. otherwise you might just like to switch to KDE. AFAIK, GNOME has no kiosk mode support nor any interest in providing such. -- Oded ::.. The first time I encountered setjmp() was in an Amiga program ported from Unix. Hmm, what's setjmp()? I said, pulling up the man page. I read the man page. *GASP* GLARGGGPPPHHTT!!! [EMAIL PROTECTED]^U! I exclaimed, and rolled my chair over backwards as I fainted. -- From: [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Windows Security Model (Configuring GDM to limit user actions)
Well then, I'm just not the type. I'll elaborate. On Tuesday 10 February 2004 10:32, Oron Peled wrote: On Tuesday 10 February 2004 05:28, Ez-Aton wrote: ... starting from Windows 2000 (i don't count WinNT as a real OS anyhow), First an unrelated observation. Through the years I used to hear: Windows for Worgroups isn't real OS -- Win95 is true 32bit OS Win9X is just a graphical shell -- WinNT is modern design done by the same people who did VMS WinNT is obsolete -- W2K is the future and I'm waiting for: W2K is the old world OS -- W2K server and .Net are true revolution This isn't against you specifically Ez, every Win* user I know thinks the *previous* Windows sucks big time... isn't it weird? Not exactly. For some time now, Windows 2003 Server is at hand, and I still claim Windows 2000 to be a good product (generally speaking). Windows 2000 Server implements the AD mechanism (unlike Win2000 Pro), but it's not a kernel based part, but a module, you can run the system without (AD Maintenance mode). Personally I'll take any day my first old slackware (kernel 0.99pl14) with its FVWM (with GoodStuff config) -- it was functional, fast and stable. And now to the important subject... Although we're a Linux list, knowing our competitors is an advantage, to my knowledge, Agreed (at least by me). in AD, ... [description of ActiveDirectory relevant part] Organization of various settings in a global hierarchy is an important feature that generally eases administration. I'd like to put it in some perspective: 1. Sometimes a valid idea is designed badly -- The famous example is the Windwos Registry which had the same hierarchical organization but was designed as monolithic binary file which everyone need to access... not a pretty sight. Nowdays, Registry resides in three files, each one is a special branch or hive - System, Software, Users, and each user has his/her own registry part inside his homedir (a user.dat file in ~/) Note: the utmp/wtmp in Unix/linux present exactly the same design mistake which explains the low validity of data you find there... 2. As a counter-example you may look at Linux GConf -- basically it's the registry idea done the right way: decouple storage from interface (curret plugins are XML, but that may be change), not a single repositoty but several configurable ones (system-wide, per-user, etc.), fits nicely with the regular permission model (each user has its own gconfd, no suid access). Never did try. Can't say anything about it. 3. For site-wide hierarchical management many use LDAP. It is already integrated in the important infrastructural applications -- login, (via pam) Mail (sendmail, postfix, imap4, etc.) and more. Agree. But it's not the native way of doing things, yet. Implementing an LDAP schema is based on picking up the correct schema, while, although it reduces the choise, AD (which is based on LDAP and Kerberos) has already built-in schema. But one of your points is that this isn't integrated into every application or the kernel (god forbid :-) like AD is in Windows. I'll try to refer to this point later. It is not integrated into the kernel in Windows either. ... setup access rights to most parts of Windows settings, and applications, enforce settings ... This is a very important issue. The Linux kernel has implemented internally capability based security for quite some time. However, almost no one uses it. True. Ever asked why? I think one of the problems we have in attaching security information to the user login, is that there are many cases of non-login usage: - Someone is running a process via rsh/ssh (this isn't login). - Someone is using my DISPLAY (consuming resources). - Someone is using my disk via NFS (again,... resources). - Packets are being routed via my computer (there are no user credentials in the packets at all..) Agree. Let's combine the above points into a real-life scenario: I seat at computer A running via SSH a program on computer B (with its DISPLAY apears on A of course). The program was loaded from my NFS server C and establish a connection to a server D, and the packets are routed through router E. Now since the user activity is distributed, it's non-trivial to apply some central policy to his actions. Not exactly. You could, through a central LDAP/other directory, which Computers A, B C are to AAA agains, the rules which apply to a specific user/computer. If you're permitted to use DISPLAY on other computer, but allowed to run only X,Y Z, that's what you'll run (Computer B now). Computer A asks if it's allowed to show DISPLAY, for who and from where, Computer B checks if you're allowed to run the software you're running, your server, D, checks what are your permissions regarding NFS, quota, etc, and computer E checks the source, target, and may be given
Re: Windows Security Model (Configuring GDM to limit user actions)
Ez-Aton wrote: Well then, I'm just not the type. I'll elaborate. On Tuesday 10 February 2004 10:32, Oron Peled wrote: On Tuesday 10 February 2004 05:28, Ez-Aton wrote: ... starting from Windows 2000 (i don't count WinNT as a real OS anyhow), First an unrelated observation. Through the years I used to hear: Windows for Worgroups isn't real OS -- Win95 is true 32bit OS Win9X is just a graphical shell -- WinNT is modern design done by the same people who did VMS WinNT is obsolete -- W2K is the future and I'm waiting for: W2K is the old world OS -- W2K server and .Net are true revolution This isn't against you specifically Ez, every Win* user I know thinks the *previous* Windows sucks big time... isn't it weird? Not exactly. For some time now, Windows 2003 Server is at hand, and I still claim Windows 2000 to be a good product (generally speaking). Windows 2000 Server implements the AD mechanism (unlike Win2000 Pro), but it's not a kernel based part, but a module, you can run the system without (AD Maintenance mode). Wel, it would stand to reason Microsoft will include *some* enhancement in their newer products... I, for one, still see NT4 is the their best corporate desktop environment. It's not surprising that when faced with the prospect of migrating to w2k, the Linux/Samba combo suddenly appeared so appropriate. Personally I'll take any day my first old slackware (kernel 0.99pl14) with its FVWM (with GoodStuff config) -- it was functional, fast and stable. [snip] 3. For site-wide hierarchical management many use LDAP. It is already integrated in the important infrastructural applications -- login, (via pam) Mail (sendmail, postfix, imap4, etc.) and more. Agree. But it's not the native way of doing things, yet. Implementing an LDAP schema is based on picking up the correct schema, while, although it reduces the choise, AD (which is based on LDAP and Kerberos) has already built-in schema. So does any LDAP compliant directory (including OpenLDAP). You do not want to make up schema as you go along. Other ldap servers also offer much better documentation. [snip] I'm not sure I understand what you mean by enforced. Does it change the settings in the Explorer preferences? Than this is not enforcement because it depends on the cooperation of the Explorer program -- What would prevent a user modifing the behaviour of Explorer? security by obscurity. It changes the settings per computer in my Domain. Yes. You had proxy settings ten minutes ago, now you don't. You can't change them back (if I decide you can't), and even if you could, give the computer then minutes on the net, and they'll be back to what I've predefined. That's the power of the GPO. This is also the weakness of it. OGO does not modify the security of settings of the registry keys (as I assumed first time I used it), but overrides them with the server stored keys. This gives a reasonably intelligent user a window (hahaha) of opportunity. The correct place to enforce proxy settings is the firewall regardless of the OS. *One* of the places. I consider OGO to be a convenient method to deploy proxy settings, not to enforce them. How do you force Proxy (actually, in my case - no-proxy) settings for your clients on the firewall? Had I used a proxy, I could implement a transparent proxy, however, I didn't want them to use a proxy anyhow... A Linux note: The old way to set proxy was via environment variables -- this had the excelent effect that you can do it at whatever level you want: - For every user -- in system login scripts. - For a single user -- in his own login script. - For a single session -- on the command line. The only downside was you have to start the application for it to take effect. I wonder why modern browsers haven't left it as a *default*. Of course if they use GConf, we can still have these properties. True. I agree. The environment variable is a good tool, although limited. You can hardly prevent a user from overaiding your settings. I don't know GConf yet, so I can't commetn about it. and do most of whatever comes to your mind. Can you run scripts? If not, than it's good only for the simple cases of variable=value settings and not places where you need to run some logic. (It's true that most settings are these simple var=value cases). You can run scripts. CMD scripts, VBS scripts, and if clients can run perl/python/BASh, these too. You can run executebles on client computers, because inside an organization, there (must be) is a trust relationship. I'm not saying LDAP on a Linux machine is a bad thing, however I'm saying that on Win2k, and using their reemplementation of the LDAP into the AD mechanism, they did a good job. Not perfect, but a good one, towards central point of control in an organization. We should learn from their successes, and from their mistakes, towards doing what we do better. Ez.
Re: Windows Security Model (Configuring GDM to limit user actions)
In the spirit of Know your enemy (well, actually I admit to be more MS oriented), I will drop my couple of cents... On Tue, 2004-02-10 at 13:41, Ez-Aton wrote: Well then, I'm just not the type. I'll elaborate. [snip] This isn't against you specifically Ez, every Win* user I know thinks the *previous* Windows sucks big time... isn't it weird? [skipping so not to start a flame bate] Not exactly. For some time now, Windows 2003 Server is at hand, and I still claim Windows 2000 to be a good product (generally speaking). Windows 2000 Server implements the AD mechanism (unlike Win2000 Pro), but it's not a kernel based part, but a module, you can run the system without (AD Maintenance mode). AD in general is a bunch of bundled services. You can remove AD from your server and can get it up and running back again. [snip] 3. For site-wide hierarchical management many use LDAP. It is already integrated in the important infrastructural applications -- login, (via pam) Mail (sendmail, postfix, imap4, etc.) and more. Agree. But it's not the native way of doing things, yet. Implementing an LDAP schema is based on picking up the correct schema, while, although it reduces the choise, AD (which is based on LDAP and Kerberos) has already built-in schema. Another important point is the lack of granular ACLs you can apply to OpenLDAP objects/attributes. AD here does IMHO much better job. It is not trivial, but very powerful. The ACL lets you easily delegate tasks to other people, while, when properly maintained, protecting you data. [snip] I think one of the problems we have in attaching security information to the user login, is that there are many cases of non-login usage: - Someone is running a process via rsh/ssh (this isn't login). - Someone is using my DISPLAY (consuming resources). - Someone is using my disk via NFS (again,... resources). - Packets are being routed via my computer (there are no user credentials in the packets at all..) Agree. In your spare time google for QoS Admission Control and IP Security Policy. In Microsoft world all the points you raised can be easily managed (although it is VERY rare to stumble on an sysadmin using those. Well... More points in my CV :) ) Let's combine the above points into a real-life scenario: I seat at computer A running via SSH a program on computer B (with its DISPLAY apears on A of course). The program was loaded from my NFS server C and establish a connection to a server D, and the packets are routed through router E. Now since the user activity is distributed, it's non-trivial to apply some central policy to his actions. See above. I can choke any Winbox in my network :) Not exactly. You could, through a central LDAP/other directory, which Computers A, B C are to AAA agains, the rules which apply to a specific user/computer. If you're permitted to use DISPLAY on other computer, but allowed to run only X,Y Z, that's what you'll run (Computer B now). Computer A asks if it's allowed to show DISPLAY, for who and from where, Computer B checks if you're allowed to run the software you're running, your server, D, checks what are your permissions regarding NFS, quota, etc, and computer E checks the source, target, and may be given details about your UID. If all computers are checking agains a directory located on computer F (with live replica to computer G), you could and should be able to maintain one security and permission directory service and tables, and no more. That's good for an organization. Sounds painful... I would prefer to see the services Kerberized. Much easier to manage. You are correct that having a central policy helps. But the hard question is if we can do it *without* sacrification of our distributed world (The network is the computer [McNeily]). No. See above. Kerberos based AAA anyone ? (I enforced Proxy settings for IE on every client computer just yesterday), I'm not sure I understand what you mean by enforced. Does it change the settings in the Explorer preferences? Than this is not enforcement because it depends on the cooperation of the Explorer program -- What would prevent a user modifing the behaviour of Explorer? security by obscurity. It changes the settings per computer in my Domain. Yes. You had proxy settings ten minutes ago, now you don't. You can't change them back (if I decide you can't), and even if you could, give the computer then minutes on the net, and they'll be back to what I've predefined. That's the power of the GPO. The correct place to enforce proxy settings is the firewall regardless of the OS. You think so ? Suppose you have a bunch of proxies and you want certain groups of users or computers to point to different proxies. Using GPO I can do it in a snap. How do you force Proxy (actually, in my case - no-proxy) settings for your
Re: Windows Security Model (Configuring GDM to limit user actions)
On Wed, 2004-02-11 at 02:17, Oron Peled wrote: On Tuesday 10 February 2004 23:49, Guy Teverovsky wrote: AD in general is a bunch of bundled services. You can remove AD from your server and can get it up and running back again. Does it mean it only affect other applications? or does the kernel somehow calls back AD to ask policy questions? This question is important because it ultimately determines the level of *enforcement* AD has over applications. This is because user space applications or libraries may be subverted in various ways and thus not respect the settings AD ordered them. Only kernel level enforcement will achieve the required effect in these cases. Let me re-phrase that: From the server(s) side: you can demote Domain Controller hosting an AD to stand-alone server. You can also boot the box without AD services loaded (used for AD restore/maintenance) Clients: you can disjoin the client from AD domain (need Addd/Remove computer to domain right - by default Local Admin). As long as the client computer is in the AD domain, the AD will enforce the security model of the client (you can control computer specific or user specific settings). I would not call it kernel level, but rather Local System Authority (LSA) level, which is not userland. I am having a hard time to define kernel level in NT based OSes (is it just me ?) Having local admin on the client might give you some leverage in default configuration and let you block the security model enforcements, but the local admin rights can be revoked using the same old buddy named GPO. So you might find yourself having local admin, but not being able to disjoin the machine from AD or block the enforcements. You can even restrict local logons without authenticating against AD. Heck... I once managed to lock myself out of a workstation by using to strict GPO and could not do anything even though I had local admin account :) Even if AD is user space only, it may still be very usefull as a central facility for controlling (cooperating) applications, but not as enforcement mechanism. Another important point is the lack of granular ACLs you can apply to OpenLDAP objects/attributes. AD here does IMHO much better job. It is not trivial, but very powerful. The ACL lets you easily delegate tasks to other people, while, when properly maintained, protecting you data. I'm not sure I follow you -- doesn't the 'access' directive in slapd.conf does exactly this? (man slapd.conf) You mean that you must restart the service ? AD does that on the wire (Ilya, thanks for pointing that out :) ). I am repeating myself, but... No inheritance, no inheritance blocking. OpenLDAP ACL is flat. Of course most (but not all) Linux filesystems don't support ACL's so your claim is valid when directed to the granularity of Linux file permissions. In your spare time google for QoS Admission Control and IP Security Policy. In Microsoft world all the points you raised can be easily managed (although it is VERY rare to stumble on an sysadmin using those. Well... More points in my CV :) ) That was interesting reading (BTW, net/sched/cls_rsvp.* implement this on standard Linux kernels at least since 2.2.19). However, to really control lan resources, the switches/routers should have some *authentication* mechanism to identify the DSBM -- otherwise people can easily highjack the network. Example: http://www.mail-archive.com/[EMAIL PROTECTED]/msg12432.html No I have to do some reading... Thanks for the pointer. I would prefer to see the services Kerberized. Now you hit the point. Kerberos solves the distributed services problem: - Because it is authenticated. - Because the client and the server don't have to trust each other. However, it seems that per user IP-policies (outside of the specific box) are still an illusion as IP packets don't carry the user information. We can dictate them only on cooperating hosts. Agreed. You can do you best to optimize the network, but meanwhile there are ways out. Guy -- = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
RE: Configuring GDM to limit user actions
Hi Arik, Thanks for your answer. How can I disable the RunAs service? How can I modify the menues? Reminder: running Gnome on RH9. David. From: Arik Baratz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Configuring GDM to limit user actions Date: Sun, 8 Feb 2004 18:58:11 +0200 -Original Message- From: Mark Veltzer [mailto:[EMAIL PROTECTED] 1. The operating system does not, per se, state which applications each user can run. If a user has running capabilities then he can launch any executable file. Even an executable file which was derived from consulting some greek all knowing oracle who can program in binary. Nope. It is definitely possible. Using group permissions, it is possible to define different levels of users who can run different applications depending on their group membership. All that's needed to do is: A. put the users in relevant groups B. restrict execute access to the binaries to the relevant groups C. prevent the users from running their own binaries, by restricting execution rights to disk space they can write into 2. The desktop may hide some buttons but this is no guaratee what so ever that the user wont be able to launch an application. You better look at buttons as fast ways of doing things and not as you can/can't separators. This is not windows we are talking about. You can limit access to the actual binaries, see my previous response. 3. No set of standard desktop applications has been certified as not allowing in some strage way to launch a shell since launching a shell is absolutely allowed in Linux (and encouraged for that matter). If your application dictates it, you can indeed restrict a user from running a shell, using the mechanism disscussed before. 4. If you take konqueror for example, it will allow you to have a shell running inside it. Konq. still needs to run the actual shell, and it runs under the UID of the launching user, so any restrictions you put on the shell will be reflected by Knoq. 5. The number of ways you could manipulate an application to launch a shell for you is so numerous that I can't really think of a large GUI application which I CANT launch a shell from by manipulating it in some way. If you limit access to the actual shell executables on your system and make sure everything the user runs is with his own privileges, you can do it. It takes work but very possible, I say 1-2 days of tinkering. 6. If this entire concept of yours is some marketing peoples idea for the users not touching our system go back to them and tell them it's a dream On the contrary, it is very possible, and I have seen it done more than once on various free-shell accounts and other places. 7. GDM is just the login application and does not control what the user sees or does not see on his desktop. The user can even login from GDM to a KDE environment. Agree. BTW: just for the record - the situation in windows is a lot worse since in most windows distributions the user has installation priveleges on the machine so he can actually halt the machine (for instance by running an installation process which removes critical files) or render the machine unbootable. In Linux he could just launch applications and not hurt anyone but himself. Quite an improvement. Actually Microsoft has enough tools to make it possible. Indeed the original configuration NT (4.0 and above) comes with does define the global user Everyone with permission to most of the hard-drive, but it is very possible to build a machine with the correct permission-set. Oh, yes, and disable the RunAs service. -- Arik ** This email and attachments have been scanned for potential proprietary or sensitive information leakage. PortAuthority(TM) Server Keeping Information Inside Vidius, Inc. www.vidius.com ** To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
RE: Configuring GDM to limit user actions
-Original Message- From: David Sapir [mailto:[EMAIL PROTECTED] Hi Arik, Thanks for your answer. How can I disable the RunAs service? Start -- Run -- Settings -- Control Panel -- Administrative tools -- Services Right-click the Run-As service, select properties, click 'Stop', change the startup mode to 'Disabled', click Ok. It's a WINDOWS service. There's no Linux parallel (except maybe sudo but that's not a service). How can I modify the menues? Reminder: running Gnome on RH9. Sorry, I don't do Linux desktop yet. I work in a Windows-oriented company. -- Arik ** This email and attachments have been scanned for potential proprietary or sensitive information leakage. PortAuthority(TM) Server Keeping Information Inside Vidius, Inc. www.vidius.com ** To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Configuring GDM to limit user actions
On the Windows side of things, starting from Windows 2000 (i don't count WinNT as a real OS anyhow), under a specific DOMAIN, you could define what actions each and every user, based on his role, group, the specific computer, or almost any other parameter, can do, and cannot do. It's called Group Policy, or GPO. Although we're a Linux list, knowing our competitors is an advantage, to my knowledge, so I'll elaborate a bit further. in AD, every item is an object, and any group of such items (Aka, one of one thousand users, computers, Domain controllers, etc.) are contained in groups called Containers. You have three default policies (which are default, and therefore, quite simplistic to begin with) which are Domain Security Policy, Domain Controller Security Policy, and Local Security Policy, which control the domain server(s) and computers in general, and inside AD Users and Computers, you could setup a Group Policy for every container, thus, enforcing predefined policies and settings on each member of this container. You could use it, as a domain administrator, of course, to force installation of a specific program(s) on client computers (which are member of this container, of course), setup access rights to most parts of Windows settings, and applications, enforce settings (I enforced Proxy settings for IE on every client computer just yesterday), and do most of whatever comes to your mind. The GPO is not a trivial issue, and it takes few days to get familiar with it, but it is a good central administration tool, and it is a powerfull one (although complicated, comparing to their Administration for the Dummies method of doing things). Not an MS lover (hell, not at all), I can say it's a great tool, and it is a very usefull one, too. Don't underestimate this you do not know. Ez. On Sunday 08 February 2004 18:58, Arik Baratz wrote: -Original Message- From: Mark Veltzer [mailto:[EMAIL PROTECTED] 1. The operating system does not, per se, state which applications each user can run. If a user has running capabilities then he can launch any executable file. Even an executable file which was derived from consulting some greek all knowing oracle who can program in binary. Nope. It is definitely possible. Using group permissions, it is possible to define different levels of users who can run different applications depending on their group membership. All that's needed to do is: A. put the users in relevant groups B. restrict execute access to the binaries to the relevant groups C. prevent the users from running their own binaries, by restricting execution rights to disk space they can write into 2. The desktop may hide some buttons but this is no guaratee what so ever that the user wont be able to launch an application. You better look at buttons as fast ways of doing things and not as you can/can't separators. This is not windows we are talking about. You can limit access to the actual binaries, see my previous response. 3. No set of standard desktop applications has been certified as not allowing in some strage way to launch a shell since launching a shell is absolutely allowed in Linux (and encouraged for that matter). If your application dictates it, you can indeed restrict a user from running a shell, using the mechanism disscussed before. 4. If you take konqueror for example, it will allow you to have a shell running inside it. Konq. still needs to run the actual shell, and it runs under the UID of the launching user, so any restrictions you put on the shell will be reflected by Knoq. 5. The number of ways you could manipulate an application to launch a shell for you is so numerous that I can't really think of a large GUI application which I CANT launch a shell from by manipulating it in some way. If you limit access to the actual shell executables on your system and make sure everything the user runs is with his own privileges, you can do it. It takes work but very possible, I say 1-2 days of tinkering. 6. If this entire concept of yours is some marketing peoples idea for the users not touching our system go back to them and tell them it's a dream On the contrary, it is very possible, and I have seen it done more than once on various free-shell accounts and other places. 7. GDM is just the login application and does not control what the user sees or does not see on his desktop. The user can even login from GDM to a KDE environment. Agree. BTW: just for the record - the situation in windows is a lot worse since in most windows distributions the user has installation priveleges on the machine so he can actually halt the machine (for instance by running an installation process which removes critical files) or render the machine unbootable. In Linux he could just launch applications and not hurt anyone but himself. Quite an improvement. Actually Microsoft has enough tools to make it
Configuring GDM to limit user actions
Hi, I would like to know how to configure Gnome on RH9 for a specific user: * control the menus from the start menu (which item will appear in the menues) * control which application a user can activate (run) * require a root password (or a previledged user password) for certain applications I did not find a suitable answer for that on the web. Maybe anyone has a lead for me to follow? If you think I cannot accomplish that in Gnome environment, please tell me which env and how to do it (or where to look for the answer), because I don't know any other GUI environments. Thanks, David. _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Configuring GDM to limit user actions
On Sunday 08 February 2004 15:34, you wrote: Hi, I would like to know how to configure Gnome on RH9 for a specific user: * control the menus from the start menu (which item will appear in the menues) * control which application a user can activate (run) * require a root password (or a previledged user password) for certain applications I did not find a suitable answer for that on the web. Maybe anyone has a lead for me to follow? If you think I cannot accomplish that in Gnome environment, please tell me which env and how to do it (or where to look for the answer), because I don't know any other GUI environments. Thanks, David. David! Your entire state of mind is so out of touch with how computers work that I don't even know where my answer should begin. Here is a feeble attempt: 1. The operating system does not, per se, state which applications each user can run. If a user has running capabilities then he can launch any executable file. Even an executable file which was derived from consulting some greek all knowing oracle who can program in binary. 2. The desktop may hide some buttons but this is no guaratee what so ever that the user wont be able to launch an application. You better look at buttons as fast ways of doing things and not as you can/can't separators. This is not windows we are talking about. 3. No set of standard desktop applications has been certified as not allowing in some strage way to launch a shell since launching a shell is absolutely allowed in Linux (and encouraged for that matter). 4. If you take konqueror for example, it will allow you to have a shell running inside it. 5. The number of ways you could manipulate an application to launch a shell for you is so numerous that I can't really think of a large GUI application which I CANT launch a shell from by manipulating it in some way. 6. If this entire concept of yours is some marketing peoples idea for the users not touching our system go back to them and tell them it's a dream. 7. GDM is just the login application and does not control what the user sees or does not see on his desktop. The user can even login from GDM to a KDE environment. Hope this helps in some way. Cheers, Mark BTW: just for the record - the situation in windows is a lot worse since in most windows distributions the user has installation priveleges on the machine so he can actually halt the machine (for instance by running an installation process which removes critical files) or render the machine unbootable. In Linux he could just launch applications and not hurt anyone but himself. Quite an improvement. -- Name: Mark Veltzer Title: Research and Development, Meta Ltd. Address: Habikaa 17/3, Kiriat-Sharet, city.holon, Gush-Dan, country.israel 58495 Phone: +972-03-5581310 Fax: +972-03-5581310 Email: mailto:[EMAIL PROTECTED] Homepage: http://www.veltzer.org OpenSource: CPAN, user: VELTZER, mailto:[EMAIL PROTECTED], url: http://search.cpan.org/author/VELTZER/ Public key: http://www.veltzer.org/ascx/public_key.asc, wwwkeys.pgp.net, 0xC71E5D38 To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Configuring GDM to limit user actions
David Sapir wrote: Hi, I would like to know how to configure Gnome on RH9 for a specific user: * control the menus from the start menu (which item will appear in the menues) * control which application a user can activate (run) * require a root password (or a previledged user password) for certain applications While logged in as root, start gdmconfig, it should give you an option to allow configuration from the login screen and many other options. Since I am not using Red-Hat I can not test it but I remember I tried it on a red-hat machine. However this configurator lets you config about 50% of the actual configuration parameters of gdm the rest is configurable from /etc/gdm/gdm.conf Hope this helps. -- Ori Idan = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Configuring GDM to limit user actions
My previous answer was about GDM, now I read your question again and see that you are talking about GNOME, I think there is a panel in gnome that lets you edit the menus. About which application a user can run, I don't think this is controllable from gnome, for this you will have to configure the premissions of each application. -- Ori Idan David Sapir wrote: Hi, I would like to know how to configure Gnome on RH9 for a specific user: * control the menus from the start menu (which item will appear in the menues) * control which application a user can activate (run) * require a root password (or a previledged user password) for certain applications I did not find a suitable answer for that on the web. Maybe anyone has a lead for me to follow? If you think I cannot accomplish that in Gnome environment, please tell me which env and how to do it (or where to look for the answer), because I don't know any other GUI environments. Thanks, David. _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
RE: Configuring GDM to limit user actions
-Original Message- From: Mark Veltzer [mailto:[EMAIL PROTECTED] 1. The operating system does not, per se, state which applications each user can run. If a user has running capabilities then he can launch any executable file. Even an executable file which was derived from consulting some greek all knowing oracle who can program in binary. Nope. It is definitely possible. Using group permissions, it is possible to define different levels of users who can run different applications depending on their group membership. All that's needed to do is: A. put the users in relevant groups B. restrict execute access to the binaries to the relevant groups C. prevent the users from running their own binaries, by restricting execution rights to disk space they can write into 2. The desktop may hide some buttons but this is no guaratee what so ever that the user wont be able to launch an application. You better look at buttons as fast ways of doing things and not as you can/can't separators. This is not windows we are talking about. You can limit access to the actual binaries, see my previous response. 3. No set of standard desktop applications has been certified as not allowing in some strage way to launch a shell since launching a shell is absolutely allowed in Linux (and encouraged for that matter). If your application dictates it, you can indeed restrict a user from running a shell, using the mechanism disscussed before. 4. If you take konqueror for example, it will allow you to have a shell running inside it. Konq. still needs to run the actual shell, and it runs under the UID of the launching user, so any restrictions you put on the shell will be reflected by Knoq. 5. The number of ways you could manipulate an application to launch a shell for you is so numerous that I can't really think of a large GUI application which I CANT launch a shell from by manipulating it in some way. If you limit access to the actual shell executables on your system and make sure everything the user runs is with his own privileges, you can do it. It takes work but very possible, I say 1-2 days of tinkering. 6. If this entire concept of yours is some marketing peoples idea for the users not touching our system go back to them and tell them it's a dream On the contrary, it is very possible, and I have seen it done more than once on various free-shell accounts and other places. 7. GDM is just the login application and does not control what the user sees or does not see on his desktop. The user can even login from GDM to a KDE environment. Agree. BTW: just for the record - the situation in windows is a lot worse since in most windows distributions the user has installation priveleges on the machine so he can actually halt the machine (for instance by running an installation process which removes critical files) or render the machine unbootable. In Linux he could just launch applications and not hurt anyone but himself. Quite an improvement. Actually Microsoft has enough tools to make it possible. Indeed the original configuration NT (4.0 and above) comes with does define the global user Everyone with permission to most of the hard-drive, but it is very possible to build a machine with the correct permission-set. Oh, yes, and disable the RunAs service. -- Arik ** This email and attachments have been scanned for potential proprietary or sensitive information leakage. PortAuthority(TM) Server Keeping Information Inside Vidius, Inc. www.vidius.com ** To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Configuring GDM to limit user actions
On Sun, Feb 08, 2004 at 06:58:11PM +0200, Arik Baratz wrote: -Original Message- From: Mark Veltzer [mailto:[EMAIL PROTECTED] 1. The operating system does not, per se, state which applications each user can run. If a user has running capabilities then he can launch any executable file. Even an executable file which was derived from consulting some greek all knowing oracle who can program in binary. Nope. It is definitely possible. Using group permissions, it is possible to define different levels of users who can run different applications depending on their group membership. All that's needed to do is: A. put the users in relevant groups B. restrict execute access to the binaries to the relevant groups C. prevent the users from running their own binaries, by restricting execution rights to disk space they can write into 2. The desktop may hide some buttons but this is no guaratee what so ever that the user wont be able to launch an application. You better look at buttons as fast ways of doing things and not as you can/can't separators. This is not windows we are talking about. You can limit access to the actual binaries, see my previous response. 3. No set of standard desktop applications has been certified as not allowing in some strage way to launch a shell since launching a shell is absolutely allowed in Linux (and encouraged for that matter). If your application dictates it, you can indeed restrict a user from running a shell, using the mechanism disscussed before. I am not sure if that would leave the system in a usable state for the user since quite a few tools use the shell behind the scenes. Test every tool you want accessible before you do that. 4. If you take konqueror for example, it will allow you to have a shell running inside it. Konq. still needs to run the actual shell, and it runs under the UID of the launching user, so any restrictions you put on the shell will be reflected by Knoq. 5. The number of ways you could manipulate an application to launch a shell for you is so numerous that I can't really think of a large GUI application which I CANT launch a shell from by manipulating it in some way. If you limit access to the actual shell executables on your system and make sure everything the user runs is with his own privileges, you can do it. It takes work but very possible, I say 1-2 days of tinkering. 6. If this entire concept of yours is some marketing peoples idea for the users not touching our system go back to them and tell them it's a dream On the contrary, it is very possible, and I have seen it done more than once on various free-shell accounts and other places. 7. GDM is just the login application and does not control what the user sees or does not see on his desktop. The user can even login from GDM to a KDE environment. Agree. BTW: just for the record - the situation in windows is a lot worse since in most windows distributions the user has installation priveleges on the machine so he can actually halt the machine (for instance by running an installation process which removes critical files) or render the machine unbootable. In Linux he could just launch applications and not hurt anyone but himself. Quite an improvement. Actually Microsoft has enough tools to make it possible. Indeed the original configuration NT (4.0 and above) comes with does define the global user Everyone with permission to most of the hard-drive, but it is very possible to build a machine with the correct permission-set. Oh, yes, and disable the RunAs service. -- Arik ** This email and attachments have been scanned for potential proprietary or sensitive information leakage. PortAuthority(TM) Server Keeping Information Inside Vidius, Inc. www.vidius.com ** To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Configuring GDM to limit user actions
There are some tools that allow you to control user's actions, read about 'sudo' (use with care, see remarks below). a nice tool to control users i found latly is 'and' (auto nicing deamon - a Luser's Attitude Readjustment Tool as described in the man page), it allows you to renice applications on the system and even kill certain applications after a defined amount of time for certain users/groups. Regards, Shlomil Mark Veltzer wrote: Re: Configuring GDM to limit user actions From: Mark Veltzer [EMAIL PROTECTED] To: David Sapir [EMAIL PROTECTED] CC: [EMAIL PROTECTED] On Sunday 08 February 2004 15:34, you wrote: Hi, I would like to know how to configure Gnome on RH9 for a specific user: * control the menus from the start menu (which item will appear in the menues) * control which application a user can activate (run) * require a root password (or a previledged user password) for certain applications I did not find a suitable answer for that on the web. Maybe anyone has a lead for me to follow? If you think I cannot accomplish that in Gnome environment, please tell me which env and how to do it (or where to look for the answer), because I don't know any other GUI environments. Thanks, David. David! Your entire state of mind is so out of touch with how computers work that I don't even know where my answer should begin. Here is a feeble attempt: 1. The operating system does not, per se, state which applications each user can run. If a user has running capabilities then he can launch any executable file. Even an executable file which was derived from consulting some greek all knowing oracle who can program in binary. 2. The desktop may hide some buttons but this is no guaratee what so ever that the user wont be able to launch an application. You better look at buttons as fast ways of doing things and not as you can/can't separators. This is not windows we are talking about. 3. No set of standard desktop applications has been certified as not allowing in some strage way to launch a shell since launching a shell is absolutely allowed in Linux (and encouraged for that matter). 4. If you take konqueror for example, it will allow you to have a shell running inside it. 5. The number of ways you could manipulate an application to launch a shell for you is so numerous that I can't really think of a large GUI application which I CANT launch a shell from by manipulating it in some way. 6. If this entire concept of yours is some marketing peoples idea for the users not touching our system go back to them and tell them it's a dream. 7. GDM is just the login application and does not control what the user sees or does not see on his desktop. The user can even login from GDM to a KDE environment. Hope this helps in some way. Cheers, Mark BTW: just for the record - the situation in windows is a lot worse since in most windows distributions the user has installation priveleges on the machine so he can actually halt the machine (for instance by running an installation process which removes critical files) or render the machine unbootable. In Linux he could just launch applications and not hurt anyone but himself. Quite an improvement. -- Name: Mark Veltzer Title: Research and Development, Meta Ltd. Address: Habikaa 17/3, Kiriat-Sharet, city.holon, Gush-Dan, country.israel 58495 Phone: +972-03-5581310 Fax: +972-03-5581310 Email: mailto:[EMAIL PROTECTED] Homepage: http://www.veltzer.org OpenSource: CPAN, user: VELTZER, mailto:[EMAIL PROTECTED], url: http://search.cpan.org/author/VELTZER/ Public key: http://www.veltzer.org/ascx/public_key.asc, wwwkeys.pgp.net, 0xC71E5D38 To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
