Slashdot Mirror

Some of their patents are on extremely useful ideas. For example, a few years back, they patented a method for allowing user processes to perform actions with Administrator privileges. Don't you Linux fans wish that you could license something like that?

Kind of true, but what about maintenance ? You basically don't put any safeguard against future errors...

Also, ensuring strings are properly terminated is one thing, but you still have to check against your buffer's size.

By using strncpy correctly you close the door to future problems; if this is really a major source of slowness in your
app, that should be apparent during profiling, and you can optimize _then_: Do not trade security for "maybe speed" :p

Here's an interesting paper by Todd Miller and Theo de Raddt on ~ the subject:
http://www.courtesan.com/todd/papers/strlcpy.html

> Did Microsoft put a GUI on http://www.courtesan.com/sudo/ ;-)

Pretty much...

Course, you know what this means now. All the people who'd previously spent all their time on Slashdot opinionating that Microsoft should adopt the Linux security model will now spend all their time on Slashdot opinionating that Microsoft stole the Linux security model :-/

> The "administrator" account that Vista creates by default is actually a standard user that
> can temporarily elevate to admin privelages on a task-by-task basis -- that's what UAC is about.

Did Microsoft put a GUI on http://www.courtesan.com/sudo/ ;-)

Sudo allows you to grant access to specific users for specific commands, and then revoke those commands later. Compare this with giving the root password to everyone, which requires the password to be changed whenever someone leaves the company (or someone's root privs are revoked).

I can grant access via sudo to users for specific commands, without giving them complete administrative access to the entire system.

When I'm using 'sudo' to do things, my environment stays the same. This means that my $PATH variable stays the same, and so does my prompt. It means that any time I say ~ it refers to /home/myusername and not /root, meaning I can get to it later.

I can set in ~/.bash_profile that I want rm to use -i by default (alias rm='rm -i') for safety, which carries over into my 'sudo' environment; doing this for root by default can cause e.g. cronjobs to hang, waiting for input that will never come.

The benefits of sudo are not limited to 'gaining root' - they are multitudinous, and apparently your coworkers have never considered versatility to be a benefit; nor, for that matter, have they done likewise for security. Perhaps they should be educated.

I'm surprised this article made the front page of /. as it arguably confuses the issue more IMHO.

The other thing added is something we call protected admin. This is a mode that administrators run in by default. If someone is configured as an admin, their basic execution happens as a standard user. When they try to do something that requires the administrator privilege, the system prompts them to see if they want to elevate to admin to complete the task, and if they consent, just that task is elevated (this is more secure that SUPERUSR ON in Unix that elevates the entire session). When the task completes, the high privileged process is torn down. The system can also be configured to require a password on elevation.

Is it just me, or is this exactly what sudo has been doing for over 25 years? Good Unix admins don't run sessions as root. They run regular user accounts and execute their admin commands using sudo to elevate just that process. In fact, at least Fedora is set up to automatically prompt for root credentials when a regular user tries to run a command that requires root privileges..

Congratulations on the fine innovation you call "protected admin," guys!

No.

the reason you can replace them with newer ones that have large drive support is because:

There's more profit in selling you a new card than letting you update the old ones! Ta-Daa!

Anyway, you can just plain skip the logic anyway. I've written ATA drivers for controllers before. I know how it's done, and I personally have done it and know that there is no restriction to what controllers can have LBA48 software written for them.

Go get the spec from t13.org ourself. All you have to do is write 4 registers twice. The drive remembers both the most recently written and the previously written value. The controller does nothing new at all.

As to bridge boards, they could be out of code space, they might have limits on the size of the data to be stored (can't store >28 bits of sector or >8 bits of sector count), or they just might want to sell new chips too.

Oxford might have made a "smart controller" and don't feel like switching over and going to "dumb mode" to get it to work. Or perhaps their controller is "too smart" and thus cannot be made to work in LBA48 mode. I know that the >8 bits of sector count (which allows transfers larger than 512KB at once) means your DMA equipment in your bridge might have to be able to do transfers larger than 128KiB. This was a problem on a device I worked on. It might be a probem on special bridge chips that DMA straight from the drive to the bus (like the Cypress USB chips).

Or perhaps they just want to sell new chips too. It doesn't matter, I never said all bridge chips can be updated to do LBA48, in fact, I believe I gave reasons you perhaps couldn't.

I can assure you this isn't the case with any PC interface, since they all have to work with the standard Windows driver in order to boot Windows, and thus have a "dumb mode" where you can write any registers in any order you'd like. You then write the 4 registers in question twice and run the DMA engine a couple times in a row (actually, Windows doesn't do transfers larger then 128KiB anyway with the default drivers) and you're there.

As I said, any PC controller can do it. Bridge chips can be different, due to various factors.

As to your last paragraph, well, again there is no requirement for LBA48 hardware. And the software is clearly running in LBA48 mode (despite being on what you call "non-LBA48 hardware"), since without it, you can only address 2^28 sectors, and thus you simply have no way to access those sectors above 128GiB.

I do appreciate applying logic to a situation. But in this case, you're wrong, and you should do some research about it before looking even more foolish.

As perhaps something to spur you to this, let me give you a link about how series 1 Tivos (which were released in 1997 or 1998) can use LBA48, with a new kernel.

http://www.courtesan.com/tivo/bigdisk.html

I know this isn't a "knockout blow" to your theory, but perhaps it is enough to spur you to look further and realize your mistake.

Finally, here's the link to the ATA spec site.

http://t13.org/#Project_drafts

Their specs aren't exactly transparent, but maybe you can learn something from those too.

In the interest of promoting a good idea I hadn't seen explained in detail before, "strlcpy and strlcat - consistent, safe, string copy and concatenation".

Hell, if we look at the fact that strlcat/cpy have been turned down for inclusion multiple times to the GNU libc because it would be "slower" when preventing a buffer vuln, if anything it's getting worse, and will continue down that slope.

strcpy(path, homedir);
strcat(path, "/");
strcat(path, ".foorc");
len = strlen(path);

strncpy(path, homedir, sizeof(path) - 1);
path[sizeof(path) - 1] = '\ 0';
strncat(path, "/",sizeof(path) - strlen(path) - 1);
strncat(path, ".foorc", sizeof(path) - strlen(path) - 1);
len = strlen(path);

strlcpy(path, homedir, sizeof(path));
strlcat(path, "/", sizeof(path));
strlcat(path, ".foorc", sizeof(path));
len = strlen(path);

This is a user action that you're faulting Microsoft for

No, these are Microsofts design flaws that you are faulting the user for. Sudo was invented in 1980. That Microsoft doesn't have an equivilant for it by now is pathetic. And no, "run as" does not come remotely close.

If they're only replacing strcpy with strncpy, they're not actually fixing the problem.

More like plain su. Sudo is a very complicated program. Just look at the sudoers file man page. Microsoft's runas doesn't compare.

sudo http://www.courtesan.com/sudo/ is your friend.

Ask them what commands they need to run and let them have sudo access to run thoes commands only. Make sure they can't edit those commands through. If they are shell/perl programs, write a simple C wrapper script and give them sudo access to that if you're really paranoid.

Even as a sysadmin for 9 years I didn't login as root. 99% of the stuff is done through sudo. Root is for console access to deal with hardware issues in single user mode and to fix NIS issues.

If you're using the sudo that came with your distro, just make sure that it is logging every time someone runs sudo. If not snag a new tarball from the URL above. It should compile right out of the, but if you're having issues, then check out the RUNSON file. It'll tell you what options to use.

good luck

...ahh here's the quote:

"How many Developers run as Administrator on their development box? Our research shows 95% or more - despite this being a known practice which introduces deployment and/or security flaws in applications downstream!"

Either way, it's an absolute PITA to do development without the freedom provided by having total access (installing third party packages/software, modifying permissions, configuring services). You can install applications like Sudo to grant elevated privileges on a case-by-case basis, but you have to be serious about it because there's a lot of configuration you have to do if you want to do it properly.

Sidenote: My colleague who used to work for a bank told me a tale where he was not allowed to see what cron jobs were running on a system, but for whatever reason - had been given access to use /bin/cat with sudo. At one stage he "cat" the /var/spool/cron/tabs/xyz (or whatever the path is), in order to find out why some process was hogging the system resources. When he offered a suggestion on how to improve it - the admin looked at him oddly and was like "how do you know what cron jobs are running!?"

I'd just ask for sudo access to the resources I needed. Also, you never said why he denied access. Does the system have trust relationships with other systems he want's you out of?

Try sudo, it's perfect for things like that.

Neither Windows nor Win32 nor Win64 is listed. Or do you suggest purchasing FreeBSD-compatible alternatives to the Windows-compatible printer, scanner, video card, and other peripherals that sconeu owns?

I don't want to give out the admin password. But for some stuff, it would be nice to setuid to admin, without having to do password check.

Short of a posting here on the official sudo site by Todd or Chris (both of whom I bet could care less) I'm gonna keep saying "Sue-Doh" out of homage to Homer Simpson. Perhaps MSFT's patent is based on the pronunciation?

In all seriousness, someone should do this as it should make this filing a nice waste of at least $10K of Microsoft's money. Maybe they will get a clue and do proper prior art searches(duh, look in Unix).

Sometimes I wonder about the quality of their programmers, I think this is an obvious example that they need to get more experience using 'rival' software. Anyone who has actually used a Unix knows about this stuff, so to think they 'invented' it would be outright dishonest or more likely in this case just ignorance.

In reading the patent, it does look pretty obvious that it's doing what SUDO is doing... I think this should be blown up with little effort.

Is there any penalty for filing patents for which you KNOW prior art exists? If not, there definitely should be.

It already is!

sudo is your friend. Give said MCSE a login account with the minimum set of permissions possible, then configure sudo to give to execute /sbin/reboot (and only that command) as root. Voila - he now has the ability to execute only the command that you feel it necessary for him to have.

I get shot down every time I bring this up, but...the OpenBSD folks have a database of coding flaws that can cause vulnerabilities. Every time they find a new one, they go over all their code and fix all the other places that have it, whether they find an exploit at those spots or not. This is the process that makes them so secure. So...why not publish all this?

Whenever I bring this up, people say "just read the man pages for strncpy, you moron." Which is ironic, because if you read the paper I linked, you'll find that the OpenBSD team has found problems with strncpy, too...that's why they made strlcpy.

Even the excellent book Building Secure Software doesn't mention strlcpy.

Unfortunately a quick google for strlcpy() gave me this

Which shows it to better in a number of instances than strncpy() To be portable almost all my apps have this anyway which solves similiar issues to strlcpy.

void my_strncpy(char *s, const char *t, int n){ while((*s++ = *t++) && --n) ; *s = '\0'; }

If glibc is going to break compatibility for its next version, I think the glibc maintainers should consider removing functions which KNOWN SECURITY RISKS, such as gets(), strcpy(), strcat(), sprintf(), and friends. There are safer alternatives, such as strncpy(), strncat(), and snprintf(). If glibc removes risky functions, then application writers will be forced to improve their applications by use safer functions and coding practices. Shouldn't known "best practises" be encouraged by the libraries we use as the foundation of our software?

Unfortunately, even some of those "safe" functions can be difficult to use safely. OpenBSD, FreeBSD, NetBSD, and Solaris libc libraries include strlcpy() and strlcat(). Theo de Raadt co-wrote an insightful paper about these new functions: strlcpy and strlcat - consistent, safe, string copy and concatenation . Why does glibc insist on not supporting these safer alternatives?

If removing these risky functions is too controversial, then glibc could use a transitional approach. Move the risky functions' prototypes into a separate header file. Name it something scary like "unsafe.h", "securityrisk.h" or "bufferoverflow.h". Application writers who are too lazy to fix their use of risky functions, can simply #include "bufferoverflow.h".

Information about sudo, including docs, downloads, and mailing lists, is available at http://www.courtesan.com/sudo/index.html.

Or you could use sudo.
------

Wow, You really need to take a look at "sudo". You can give a user full super user privileges or just privileges for a specific task. As far as I know, "sudo" has been around for ages, so your argument is a fallacy.
---------
- [Darth] Snowbeam

just a couple of points about the files you listed. Keep in mind that this is for my home machines where I am the only user. I remove the suid bits from mount and umount, because I am the only one that should need to mount drives anyway. If I start giving out accounts on my home system, this is something I won't have to worry about then, as it's already been taken care of. I don't use at, so I disable it, if an exploit does happen to come out, I don't have to worry about patching it right away, but it's still a good idea to do so. The same thing goes for gpm, I don't use it when I'm in console mode, so when that exploit came out a couple of weeks ago, it wasn't a major concern.

The Bastille hardening script for RedHat based systems has the option to remove suid bits from ping and traceroute. It doesn't break them, you just have to be root to use them. There are debates about whether or not regular users should have access to tools such as ping and traceroute anyway, and it's likely I won't be the one to end the debate, but I prefer on my own machine to limit it to root. After all, I am root, and if I give out an account to a friend, he can just as easily run ping from his own machine. if you want to give permissions to some people and not others, sudo is extremely easy to install and configure and works great for limiting su access to specific users for specific applications.

Once again, a lot of this was learned from experience, I spent time using the system and learned what I need and what I don't need, and now I know what comes enabled and how to disable it shortly after install, before connecting to the Internet. This doesn't mean every vendor should ship their systems to my specs, after all, I'm a nobody and really have no say over what vendors put in their OS.

One thing I don't agree with is some of the default behaviors of certain parts of the OS. For example, a friend of mine got cracked with one of the latest wu-ftpd exploits. The attacker added a user with uid 0 and removed /etc/securetty. I don't know if you know what this does, but the default behavior is that if securetty doesn't exist, rather than restricting a root login (especially a remote one), it compalins that it can't find the file and then lets the user login anyway. For this, I would prefer the default behavior to be something more along the lines of "if /etc/securetty doesn't exist, don't let someone with uid 0 login anywhere." Even if the administrator accidently removes securetty, if they were security conscious, they would have created a non-root user, and nothing would stop them from logging in as an unpriviledged user and su'ing to root to fix the securetty file. Of course, the whole incident stemmed from him running an insecure ftpd that he didn't even need.

I don't know how many other examples there are of insecurity like this, I mean it's probably something someone just over-looked. I'm not a kernel developer, I'm trying my best not to throw stones, as I realize the kernel hackers and OS people are lightyears ahead of what I can do, but as a user, it's those kinds of things that worry me. disabling services is something I can do, re-writing the kernel or the os, I'm not quite to that level yet...

Have you considered using sudo to give selective root access to users? sudo stands for "superuser do", and allows selective superuser access. sudo lets the admin define, in a shared config file, individual executables and scripts (by full path), and who they run as. You can give a user access to /bin/rpm as root, for example, so they can install packages, without giving them access to any thing else as root. You can also define rights by group and by machine, in addition to by user. Users use their own password to perform the function, so there are no extra passwords to distribute and remember. As an added bonus, sudo logs to syslog not only that user jsmith used sudo, but the entire command line -- very useful for auditing (where su logs only that the user became root).

Technical info: sudo is developed and maintained by Courtesan Consulting; the homepage is at http://www.courtesan.com/sudo/; it is distributed under a BSD-style license; it is at version 1.6.3. It compiles easily on (at least) Linux and Solaris (using gcc and Sun's native crap-piler, er, compiler), and lets you optionally define error message (there are some included and adding your own is simple). Here's a nutshell intrioduction.

I highly recommend it. We use it all the time. It takes a little bit of planning, as well as trial and error, to setup correctly, but once it is set up, it is a huge time saver.

In your situation, you would have to set up the complete config file (called sudoers) on an shared filesystem, make sure sudo is in everyone's path, and then change the root passwords on everyone's machine. You'll get a lot of complaints at first, naturally, and then you'll get a lot of requests like "Why can't I run foobarbaz.pl anymore?", which you would either have to add to the sudoers file or beat down the request.

darren

Have you considered using sudo to give selective root access to users? sudo stands for "superuser do", and allows selective superuser access. sudo lets the admin define, in a shared config file, individual executables and scripts (by full path), and who they run as. You can give a user access to /bin/rpm as root, for example, so they can install packages, without giving them access to any thing else as root. You can also define rights by group and by machine, in addition to by user. Users use their own password to perform the function, so there are no extra passwords to distribute and remember. As an added bonus, sudo logs to syslog not only that user jsmith used sudo, but the entire command line -- very useful for auditing (where su logs only that the user became root).

Technical info: sudo is developed and maintained by Courtesan Consulting; the homepage is at http://www.courtesan.com/sudo/; it is distributed under a BSD-style license; it is at version 1.6.3. It compiles easily on (at least) Linux and Solaris (using gcc and Sun's native crap-piler, er, compiler), and lets you optionally define error message (there are some included and adding your own is simple). Here's a nutshell intrioduction.

I highly recommend it. We use it all the time. It takes a little bit of planning, as well as trial and error, to setup correctly, but once it is set up, it is a huge time saver.

In your situation, you would have to set up the complete config file (called sudoers) on an shared filesystem, make sure sudo is in everyone's path, and then change the root passwords on everyone's machine. You'll get a lot of complaints at first, naturally, and then you'll get a lot of requests like "Why can't I run foobarbaz.pl anymore?", which you would either have to add to the sudoers file or beat down the request.

darren

Have you considered using sudo to give selective root access to users? sudo stands for "superuser do", and allows selective superuser access. sudo lets the admin define, in a shared config file, individual executables and scripts (by full path), and who they run as. You can give a user access to /bin/rpm as root, for example, so they can install packages, without giving them access to any thing else as root. You can also define rights by group and by machine, in addition to by user. Users use their own password to perform the function, so there are no extra passwords to distribute and remember. As an added bonus, sudo logs to syslog not only that user jsmith used sudo, but the entire command line -- very useful for auditing (where su logs only that the user became root).

Technical info: sudo is developed and maintained by Courtesan Consulting; the homepage is at http://www.courtesan.com/sudo/; it is distributed under a BSD-style license; it is at version 1.6.3. It compiles easily on (at least) Linux and Solaris (using gcc and Sun's native crap-piler, er, compiler), and lets you optionally define error message (there are some included and adding your own is simple). Here's a nutshell intrioduction.

I highly recommend it. We use it all the time. It takes a little bit of planning, as well as trial and error, to setup correctly, but once it is set up, it is a huge time saver.

In your situation, you would have to set up the complete config file (called sudoers) on an shared filesystem, make sure sudo is in everyone's path, and then change the root passwords on everyone's machine. You'll get a lot of complaints at first, naturally, and then you'll get a lot of requests like "Why can't I run foobarbaz.pl anymore?", which you would either have to add to the sudoers file or beat down the request.

darren

Have you considered using sudo to give selective root access to users? sudo stands for "superuser do", and allows selective superuser access. sudo lets the admin define, in a shared config file, individual executables and scripts (by full path), and who they run as. You can give a user access to /bin/rpm as root, for example, so they can install packages, without giving them access to any thing else as root. You can also define rights by group and by machine, in addition to by user. Users use their own password to perform the function, so there are no extra passwords to distribute and remember. As an added bonus, sudo logs to syslog not only that user jsmith used sudo, but the entire command line -- very useful for auditing (where su logs only that the user became root).

Technical info: sudo is developed and maintained by Courtesan Consulting; the homepage is at http://www.courtesan.com/sudo/; it is distributed under a BSD-style license; it is at version 1.6.3. It compiles easily on (at least) Linux and Solaris (using gcc and Sun's native crap-piler, er, compiler), and lets you optionally define error message (there are some included and adding your own is simple). Here's a nutshell intrioduction.

I highly recommend it. We use it all the time. It takes a little bit of planning, as well as trial and error, to setup correctly, but once it is set up, it is a huge time saver.

In your situation, you would have to set up the complete config file (called sudoers) on an shared filesystem, make sure sudo is in everyone's path, and then change the root passwords on everyone's machine. You'll get a lot of complaints at first, naturally, and then you'll get a lot of requests like "Why can't I run foobarbaz.pl anymore?", which you would either have to add to the sudoers file or beat down the request.

darren

Have you considered using sudo to give selective root access to users? sudo stands for "superuser do", and allows selective superuser access. sudo lets the admin define, in a shared config file, individual executables and scripts (by full path), and who they run as. You can give a user access to /bin/rpm as root, for example, so they can install packages, without giving them access to any thing else as root. You can also define rights by group and by machine, in addition to by user. Users use their own password to perform the function, so there are no extra passwords to distribute and remember. As an added bonus, sudo logs to syslog not only that user jsmith used sudo, but the entire command line -- very useful for auditing (where su logs only that the user became root).

Technical info: sudo is developed and maintained by Courtesan Consulting; the homepage is at http://www.courtesan.com/sudo/; it is distributed under a BSD-style license; it is at version 1.6.3. It compiles easily on (at least) Linux and Solaris (using gcc and Sun's native crap-piler, er, compiler), and lets you optionally define error message (there are some included and adding your own is simple). Here's a nutshell intrioduction.

I highly recommend it. We use it all the time. It takes a little bit of planning, as well as trial and error, to setup correctly, but once it is set up, it is a huge time saver.

In your situation, you would have to set up the complete config file (called sudoers) on an shared filesystem, make sure sudo is in everyone's path, and then change the root passwords on everyone's machine. You'll get a lot of complaints at first, naturally, and then you'll get a lot of requests like "Why can't I run foobarbaz.pl anymore?", which you would either have to add to the sudoers file or beat down the request.

darren