bgt@cbnewsh.ATT.COM (barbara.tongue) (07/04/89)
Folks, I have a question concerning at command. Why does it neet the setuid bit? Why does it need root permissions? That seems like a slight security hazard to me... Please email in response. Thanks! -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% The Speaking Tongue, AT&T %% C Code. C Code Run. Run, Code, RUN! %% %% (..!att)!feathers!bgt %% PLEASE!!!! %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
hutch@lzaz.ATT.COM (R.HUTCHISON) (07/05/89)
From article <1894@cbnewsh.ATT.COM>, by bgt@cbnewsh.ATT.COM (barbara.tongue): > Folks, > > I have a question concerning at command. Why does it > neet the setuid bit? Why does it need root permissions? > That seems like a slight security hazard to me... > > Please email in response. > > Thanks! > > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %% The Speaking Tongue, AT&T %% C Code. C Code Run. Run, Code, RUN! %% > %% (..!att)!feathers!bgt %% PLEASE!!!! %% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I believe that the setuid bit is set on the shell script itself so the at command can tell if someone has been messing with it. At least on my system, the "at" shell scripts are owned by the person who executed the "at" command. When the "at" daemon is run, it assumes the identity of the owner of the file and executed the commands found therein. If it finds that the ownership has changed, it won't execute the script. But, how does it do this? read on... Scenario: If I wanted to be sneaky (and if "at" wasn't very smart), I could submit a "nasty" at job, go to the spool directory, and change the file's owner id to a target login and "at" would do the nasty to that login. file in /usr/spool/cron/atjobs after it was submitted through "at" permissions: -r-Sr-Sr-- owner: hutch after I change the ownership: permissions: -r--r--r-- owner: target The "at" daemon checks to see if the set user and group id bits are still on. If so, it assumes that all is OK and goes adead and executs the script. If it sees them off, it assumes that probably someone has tried to change the ownership of the file and is doesn't execute the script. The "at" command actually doesn't use the permission bits for their originally intended use (setuid), but rather because these bits are reset on a chown. About "at" requiring "root" permission, I guess it needs it to write into the "atjobs" directory. Bob Hutchison lzaz!hutch
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (07/05/89)
In article <669@lzaz.ATT.COM> hutch@lzaz.ATT.COM (R.HUTCHISON) writes: >If I wanted to be sneaky (and if "at" wasn't very smart), I could submit >a "nasty" at job, go to the spool directory, and change the file's owner >id to a target login and "at" would do the nasty to that login. The above problem does not occur in BSD, because BSD allows only root to change file ownership. When you discuss a security problem that is specific to System V, please be sure to say so clearly, else you may confuse naive users. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
peter@ficc.uu.net (Peter da Silva) (07/06/89)
In article <8072@bsu-cs.bsu.edu>, dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: > The above problem does not occur in BSD, because BSD allows only root > to change file ownership. I certainly hope that V.4 doesn't have this *bogus* restriction. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. Personal: peter@sugar.hackercorp.com. `-_-' Quote: Have you hugged your wolf today? 'U`
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (07/06/89)
An AT&T salesman earnestly told me that System V Release 3 does have a
disk quota mechanism. I told him this was news to me. What this has
to do with the following is left as an exercise for the reader.
I said:
...BSD allows only root to change file ownership.
In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
I certainly hope that V.4 doesn't have this *bogus* restriction.
My response:
I doubt that it will need to.
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
peter@ficc.uu.net (Peter da Silva) (07/06/89)
In article <8092@bsu-cs.bsu.edu>, dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: [no disk quotas in V.3] > I said: > ...BSD allows only root to change file ownership. > In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > > I certainly hope that V.4 doesn't have this *bogus* restriction. > I doubt that it will need to. I hope you're right. But remember that V.4 is supposed to be V.3+BSD. Does anyone here really know what sort of crud V.4 (not V.3) is going to have in it? Streams *and* sockets, or so I hear... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "Arrrrggggh! Personal: peter@sugar.hackercorp.com. `-_-' | Electronic mail sucks eggs." Quote: Have you hugged your wolf today? 'U` | -- eugene miya
uri@arnor.UUCP (Uri Blumenthal) (07/06/89)
From article <8072@bsu-cs.bsu.edu>, by dhesi@bsu-cs.bsu.edu (Rahul Dhesi): > > When you discuss a security problem that is specific to System V, > please be sure to say so clearly, else you may confuse naive users. First of all, not everybody familiar with System V, knows exactly which features of BSD (and what version!) it has or has not. So, for example, I didn't know that you can do "chown" only being root (and I consider it rather STUPID - System V solved this security hazard a lot nicer: it just clears all sticky bits!). Even wizards don't have to be familiar with all the flawors of UNIX (or tomorrow somebody will come up and say, like "but on my HP/UX it's different", or "on my A/UX", or whatever boo you can find today. Uri.
clewis@eci386.UUCP (07/07/89)
In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >In article <669@lzaz.ATT.COM> hutch@lzaz.ATT.COM (R.HUTCHISON) writes: >>If I wanted to be sneaky (and if "at" wasn't very smart), I could submit >>a "nasty" at job, go to the spool directory, and change the file's owner >>id to a target login and "at" would do the nasty to that login. >The above problem does not occur in BSD, because BSD allows only root >to change file ownership. 1) it isn't a problem in SV, 'cause at won't run it. Like he said. Because, even though you can chown a file away from yourself, at will insist that the setuid bits are set before believing the ownership of the file. And, when you chown, the setuid bits are turned *off*. And you can't turn 'em on once you've given the file away. 2) BSD *does* allow you to give files away. It turns off the setuid bits too. If it doesn't work on your system, obviously someone disabled it for accounting reasons. >When you discuss a security problem that is specific to System V, >please be sure to say so clearly, else you may confuse naive users. It wasn't necessary for him to say so, because it *isn't* a security problem. "at" needs setuid root permissions so that it can write in the cron/at spool directories. In SVR3, there's no specific utility to run the "at" jobs, they seem to be simply shovelled into cron. -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
guy@auspex.auspex.com (Guy Harris) (07/07/89)
> I doubt that it will need to.
Considering the BSD file system in S5R4 is intended to have support for
disk quotas, then yes, it *will* need to permit you to disallow giving
away files. It will probably be a configuration option.
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (07/07/89)
In article <228@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: [ objecting to my recommendation "when you discuss a security problem that is specific to System V, please be sure to say so clearly, else you may confuse naive users." ] >First of all, not everybody familiar with System V, knows exactly which >features of BSD (and what version!) it has or has not. So, for example, >I didn't know that you can do "chown" only being root... The problem is easily solved. Don't say (or even imply) "UNIX" at all unless you are sure you are making a general statement. Just mention specifically what operating system and revision level you are discussing (e.g. "System V Release 3" or "4.3BSD"). -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
guy@auspex.auspex.com (Guy Harris) (07/07/89)
> 2) BSD *does* allow you to give files away. No, it doesn't - not vanilla 4.xBSD, anyway; you have to be root to change the ownership of a file. It may allow you to make some limited changes to the *group* IDs of files you own, but that's a different matter. >In SVR3, there's no specific utility to run the "at" jobs, they seem to >be simply shovelled into cron. Yup, "cron" runs 'em both, and has since S5R2.
dricejb@drilex.UUCP (Craig Jackson drilex1) (07/08/89)
In article <1880@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >> I doubt that it will need to. > >Considering the BSD file system in S5R4 is intended to have support for >disk quotas, then yes, it *will* need to permit you to disallow giving >away files. It will probably be a configuration option. At the SVR4 BOF at the Baltimore Usenix, the presenters did state that there would be a configuration option for chown behavior. Evidently, it will be either a config-time option or a boot-time option, and it will be system-wide. I think the chown issue is largely one of usage--at Universities, where there are a large number of independent users who must be treated as malicious, quotas are valuable, and disallowing chown is one of the costs of quotas. At commercial sites, a given file system will be supporting only a few projects, there is no such thing as academic freedom, and the boss's opinion of who's hogging the disk will always win. In that environment, allowing give-away chowns is useful, and there really isn't much reason not to. (How many commercial sites run with quotas enabled? On how many file systems?) What one would really want is some sort of permission matrix. (Mary and John can chown with each other. Professors can chown with abandon amongst themselves, but lowly undergraduates cannot chown at all.) Such a thing is really more complicated than the Unix philosophy normally allows. Perhaps the quota system could be expanded to handle this. When Unix gets ACLs (Access Control Lists), it would be nice to fold this sort of thing into that implementation. -- Craig Jackson {bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
wilber@alice.UUCP (Bob Wilber) (07/08/89)
Chris Lewis writes: >"at" needs setuid root permissions so that it can write in the cron/at >spool directories. Actually, "at" shouldn't have to run setuid to root. A special user (say, "Mr.At") should be created to own the at spool directory, and "at" should run setuid to Mr.At. That way if someone discovers a security hole in "at" he only gains the power to delete other people's at files, he doesn't get to play super user. The real reason "at" is run setuid to root on System V is because of the infamous System V setuid(2) bug, wherein a process with a non-root effective id is not able to setuid to its real id if that real id is root. Because of this bug "at" must be run setuid to root so that root can use it. Bob Wilber
allbery@ncoast.ORG (Brandon S. Allbery) (07/09/89)
As quoted from <669@lzaz.ATT.COM> by hutch@lzaz.ATT.COM (R.HUTCHISON): +--------------- | About "at" requiring "root" permission, I guess it needs it to write | into the "atjobs" directory. +--------------- at needs root permissions so it can setuid() itself to the owner of the at job file, so it can execute the job as the user who submitted it. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
wilber@alice.UUCP (Bob Wilber) (07/10/89)
Brandon S. Allbery writes: >at needs root permissions so it can setuid() itself to the owner of the at >job file, so it can execute the job as the user who submitted it. No. "at" doesn't execute the job file, "atrun" does. (Or, on some systems, cron itself.) "at" only needs the ability to create a file in the at spool directory. As I stated in my previous post, this shouldn't require root capabilities, but on System V, a bug in the setuid(2) command forces "at" to be run setuid to root. Bob Wilber
peter@ficc.uu.net (Peter da Silva) (07/10/89)
I thought at(1) needed root permissions so it could run scripts under each user's own id. If there's some other way that at(1) could run a program setuid to an arbitrary user than by being root (or by invoking another program setuid to root) I'd be mighty interested. Unless you want to radically change the semantics of at(1), at scripts are basically setuid shell scripts. Given the effort at(1) goes to to retain the rest of the invoking user's environment, I don't see that this is desirable. One thing that at(1) needs to do, at least on SVR3, is to save the ulimit somewhere that it can be used while uid is still root. It's possible for a user's ulimit to be bigger than cron(1)'s. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "try out a seldom-used feature Personal: peter@sugar.hackercorp.com. `-_-' | of C -- the ``comment''." Quote: Have you hugged your wolf today? 'U` | -- David Gelhar.
clewis@eci386.uucp (Chris Lewis) (07/12/89)
In article <1882@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >> 2) BSD *does* allow you to give files away. >No, it doesn't - not vanilla 4.xBSD, anyway; you have to be root to >change the ownership of a file. It may allow you to make some limited >changes to the *group* IDs of files you own, but that's a different matter. H'm - thinking back on it, ours was distinctly not vanilla (not to mention the dual-VAX Purdue mods). -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425