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!dhesipeter@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
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (07/08/89)
In article <228@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: >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. USG manuals and the SVID are a good indication of a feature being in ``Real UNIX[tm]''. It is BSD that confuses naive users. And indeed wizards are quite familiar with the behavior of major variations of UNIX. -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | "Computer security is to information InterNet: jfh@rpp386.cactus.org | control as a chastity belt is to UucpNet : <backbone>!bigtex!rpp386!jfh +- birth control" -- Doug Steves --
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (07/08/89)
In article <8122@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >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"). The problem is even more easily solved than that. Try to remember that the string ``UNIX'' is a registered trademark of AT&T which is used [ according to their lawyers ;-) ] to describe a particular product produced by AT&T. Since we are all using the most recent ;-) implementation of that AT&T product, it should be safe to assume ``UNIX'' describes S5R3, until such time as S5R4 is released. -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | "Computer security is to information InterNet: jfh@rpp386.cactus.org | control as a chastity belt is to UucpNet : <backbone>!bigtex!rpp386!jfh +- birth control" -- Doug Steves --
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
allbery@ncoast.ORG (Brandon S. Allbery) (07/09/89)
As quoted from <13809@ncoast.ORG> by allbery@ncoast.ORG (Brandon S. Allbery): +--------------- | 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. +--------------- Whoops! Open mouth, insert foot.... ;-) The run-jobs side of "at" needs root for that -- but the run-jobs side is cron. "at" needs root permissions to write to /usr/lib/cron/FIFO and thereby notify cron that something has changed. (FIFO is writable only be root, again for security reasons.) Gotta stop posting news before my first cup of coffee in the morning ;-) ++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.
uri@arnor.UUCP (Uri Blumenthal) (07/11/89)
From article <16774@rpp386.Dallas.TX.US>, by jfh@rpp386.Dallas.TX.US (John F. Haugh II): >>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. > > And indeed wizards are quite familiar with the behavior of major > variations of UNIX. Well, wizards shouldn't be "naive" - so they can't be confused so easily, can they? And I bet that not every wizard really knows the behavior of all the pieces of all the major variations of UNIX (at least 4 of them, so far). Uri.
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
limes@sun.com (Greg Limes) (07/18/89)
In article <269@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes:
Well, wizards shouldn't be "naive" - so they can't be confused so easily,
can they? And I bet that not every wizard really knows the behavior of
all the pieces of all the major variations of UNIX (at least 4 of them,
so far).
I was under the distinct impression that part of the qualifications for
being a "wizard" is to know when you have reached the limit of your
wizardliness, and act appropriately.
But then, I have a few years to go before I will qualify as a wizard, and
may have overstepped my limits -- I better go back to patching running
kernels with cat :-)
--
Greg Limes limes@sun.com ...!sun!limes 73327,2473 [chose one]